Hacker News Reader

Comment by pmoleri | Hacker News Reader

> * major features are done in feature branches, w/rebasing prior to merge

Rebase in a feature branch, that can be long-lived and have many commits, seems like a painful experience to me.

You can end up solving the same conflict more than once, or even solving conflicts that don't exist in the final result. no-ff merge commits are usually easier to solve.

Am I missing something? Is there an easier rebase strategy?

View on HN

Sometimes it's painful, normally it's not, and yes - the longer lived it is the more painful it's likely to be.

no-ff merges are easier, but leave a messier non-sequential history of when things actually go out which is sometimes confusing when understanding why things are the way they are; I generally, but not always, judge it to be worth the pain!

Same. I think people just have different ideas of what "long lived" means. To some it might be a few days of work, to some weeks.

We actually merge the master into our long lived feature branches first. Then run all the tests on that branch, if it's good it can be directly merged into master (master is locked, and you need permission to commit anything to it).

I think so. Sometimes we have long-lived branches with multiple contributors for new features. Is this some kind of anti-pattern? We don't use feature flags, they seem hard to maintain and restrictive in terms of what you can do (e.g. structural changes). OTOH, because we're a small team, when there's a lot of work in a new feature branch there's little work on master, so there's little hassle there too.

Reply on news.ycombinator.com