4 ms·
I 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, o
by samstokes 16y ago
I 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?