Hacker News Reader

Comment by ShinTakuya | Hacker News Reader

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.

View on HN

> 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