On 10/05/2011 12:10 PM, Richard Heck wrote:
On 05/10/2011 11:37 AM, Stephan Witt wrote:
Am 10.05.2011 um 17:27 schrieb Vincent van Ravesteijn:
There are
plenty of cases where a bug gets fixed in trunk first, and then we wait
to commit to branch until we see how that goes.
In the development model I propose, we fix a bug in a topic branch.
This branch will regularly be merged into a
testing branch which is comparable to the current svn trunk. When a
feature is cooked, tested, or if we have seen how it goes, the feature
will be merged either into master (a sort of stable trunk) or it will be
merged into BRANCH_2_0_X. All fixes that are merged into
BRANCH_2_0_X will of course get merged into the stable trunk
as well when BRANCH_2_0_X get merged into master.
So, if a bug is attacked in a branch and this lasts a while you need to remerge
the BRANCH_2_0_X regularly into your bug fixing branch(es), right?
Yes, or probably better: rebase against BRANCH_2_0_X. That merges and
then records all your changes to branch as "most recent" commits.
Merging alone makes the more recent commits to BRANCH_2_0_X look later
than your changes. I.e., merging gives you a commit history like:
BRANCH Tuesday --> bug fixing --> BRANCH Wednesday --> BRANCH Thursday
whereas rebasing gives you:
BRANCH Tuesday--> BRANCH Wednesday --> BRANCH Thursday --> bug fixing
Getting used to that kind of difference is one of the things involved in
getting used to git.
Richard
That's the best explanation of it that I have read. So rebasing is
similar to svn up in our case. If you do it often enough I guess you
could catch the potential for merge conflicts early rather than late.
Except that because we would be using feature branches, the change from
BRANCH Wednesday --> BRANCH Thursday might include a largish marge from
a feature branch which involves large merge conflicts.
--
Julien
