Re: proper way to merge?
- From
John Tapsell <johnflux@gmail.com>
- Date
- Mar 3, 2009, 05:01 UTC
- Message-ID
- <43d8ce650903022101x584d7dcfr1758efc5e2c2e5cc@mail.gmail.com>
- In-Reply-To
- <450196A1AAAE4B42A00A8B27A59278E709F07432@EXCHANGE.trad.tradestation.com>
2009/3/2 John Dlugosz <JDlugosz@tradestation.com>:
Show 12 quoted lines
> ===Re:=== > Instead of merge, I prefer to rebase. so: > > git checkout dev > git rebase origin rel > > This replays each commit made in 'dev' on top of release, letting you > fix each commit separately. It also means that when I commit to > release, the changes are a nice tree. > ===end=== > > The reason I'm doing this -- why I took over maintenance of the repository -- is because I strenuously objected to his plan to "rebase". NO! Merge, don't rebase. Besides never rebasing published branches, in this case it works much better the other way around: dev made systemic changes, and rel is mostly patches and completely new pieces of code. After looking at what was in dev..rel and what was in rel..dev, I chose to start with dev and bring in the commits from rel in a controlled manner.
It depends on what you're doing :-) I find that if the branch is too large to easily rebase, then it's probably too large entirely :) Developers don't like master to change in large ways suddenly - makes it hard for all the other branches.
It also makes it impossible to bisect, something that I find essential. If you are combining two trees which are too big to easily rebase, then there's a high chance that something will break either due to their individual changes or because of a mistake while merging. In such a case, it's then impossible to bisect to try to pinpoint the actual problem.
It will be interesting to hear your view on merging vs rebasing after a year or so of trying both.
John