Hacker News Reader

Comment by Double_a_92 | Hacker News Reader

If you got a long-lived branch is extremely cumbersome to rebase that everytime you need something from master, especially if you are not the only developper on it.

Maybe our stories are too big, but a feature branch in our company lives at least 3-4 weeks with 4 developers working on it.

The only time I use rebase is when I got local commits, and I want to pull changes from my team mates also working on the same branch.

View on HN

More everyone rebases - less cumbersome it gets. People start structuring their code across time, not just using the commits as dumps.

Yep exactly, also makes the code easier to test, understand, and less susceptible to loss of time due to context switching (since you can read those 20 lines of code you wrote and remember where you were up to in a shorter time).

It's okay to have a long lived branch. But you should be cherry picking commits from it to master regularly and rebasing on master even more regularly. It's always possible to do so, and I'm happy to explain how it can be done if you think I'm wrong.

If you cherry pick to master regularly, rebases on master are never cumbersome.

> cherry picking commits from it to master regularly

Surely the whole point of a long-lived branch is to contain stuff that's not in master - ie things that are being deliberately kept out of it?

Sure, and that's what you can do. For instance, for a website the long lived branch can contain a commit adding a link to a new feature on the homepage, only cherry picking that aspect at the very end of development so that you can work on the feature in shadow.

The point is that you merge anything that is safe to merge, which is usually most of the code if you find a way to hide it or otherwise incrementally change things.

Huh, I’ve used this development pattern before, but never re-used the same branch after merging code into master. I’d keep the new feature behind a configurable flag so it could be enabled in local or dev environments. Multiple branches might get created and merged to master over time. The feature would be tested in the dev environment (and maybe on a subset of users in prod), before the flag is flipped to enable the feature in prod.

That's actually my preferred way of doing it too, I was more explaining how a long lived branch can be useful while still not having to deal with merge conflicts when using cherry picking.

Reply on news.ycombinator.com