3 ms·
Rebase makes long-lived branches much more manageable. Everyone who's worked with one knows that long-lived branches are a bad idea - the performance-improveme
by samstokes 16y ago
Rebase makes long-lived branches much more manageable.
Everyone who's worked with one knows that long-lived branches are a bad idea - the performance-improvements branch that the intern started last year and has been running on beta for a while but hasn't really kept up to date with the new features we added on production. The time required to merge one of these seems to grow faster than linearly with the time since it diverged, and a year-old branch is basically impossible to merge.
However, long-lived branches happen (features get shelved and then picked up again, refactoring gets postponed due to deadlines...). Rebase doesn't make long-lived branches a good idea, but it makes them much easier to deal with:
* you can rebase once a week and keep your branch up to date (to avoid the superlinear growth of merging effort). You can just about do this with frequent "latest changes from master" merges, but it clutters the branch history, and merge commits complicate things if you ever need to rebase. (Also, anyone who tried to do this with Subversion probably got shivers down their spine at the thought of merging the branch back in after all those merges from master.)
* when the branch inevitably conflicts with master, it's much easier and less risky to resolve the conflicts a commit at a time, rather than resolving them all at once as a merge would force you to.
- eru 16y agoBy the way, the technique of rebasing every once a week to keep merge/rebase-conflicts manageabable, can of course also be applied virtually: Suppose you have a year old branch; instead of doing one mega merge, you can do 52 small merges. If the merge conflicts really grow faster than linear, divide-and-conquer will save you time.
- samstokes 16y agoI assume you mean divide-and-conquer the feature branch history into segments, and merge a segment at a time into master? That can work well. Unfortunately, often the reason you have a long-lived branch is because it's some stop-the-world change (e.g. "refactor data model") which is pretty much all-or-nothing. Of course it's always possible with enough discipline to turn a stop-the-world change into a series of incremental steps, and usually it's well worth that effort (for risk management etc) - but sometimes that's not feasible.
- eru 16y agoWith divide-and-conquer, I meant, when you are finished with your long lived branch, don't merge/rebase it outright with/on your current master branch. Just keep rebasing it forward week by week of last year. (Of course this should not happen in real time, since you have to catch up.) So a stop the world change is still doable with this model---your commit history will just pretend that you finished your branch within a week.
- samstokes 16y agoAh: yes, very good point. That's another option rebase gives you that you pretty much can't do with merges. (Throwaway merges plus rerere will give you some of the benefit, but it's not as good as incrementally bringing your branch up to date.)
- eru 16y agoWhy? It should be even the same process with merges, or isn't it?
- stevejohnson 16y agoI would say that your problems were not caused by a long-running branch per se, but rather were caused by the intern not pulling from production often enough. Linus talked about this in one of his Git talks. Responsibility for merging should lie with the team working on the new feature in the side branch, not some other team that knows nothing about it.
- samstokes 16y agoAgree (the intern was hypothetical, but agree that long-lived branches are usually symptoms of human rather than tooling problems). However these things happen, and if you are in a hole, it's nice if your tools let you dig yourself out :)