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
