Re: Questions about branches in git

> Mike Linck <mgl@absolute-performance.com> writes:
>
>> I understand that there are mechanism kind of available to address
>> this problem.  If we (all developers in my company) remember always to
>> rebase -i before they merge their topic branches back in, then it
>> could be squashed making it easier to identify and cherry pick onto
>> other branches, or *if* we always remember to rebase before we merge
>> and then create a patch set and store that on the topic branch, we
>> could kind of organize our change sets that way.
>
> On the quite contrary, probably an easier way is to pick a the oldest
> commit that a fix or enhancement would apply, build a topic that deals
> with only the fix or enhancement in question without doing anything else
> on top of it, and merge the resulting topic.  The choice of the fork point
> needs to be made wisely in such a way that the resulting topic would not
> cause too much undue conflicts when merged to a modern mainline but old
> enough that you _could_ merge the result to any older maintenance branch
> if you choose to.
>
> One implication is that you do _not_ rebase the series to newer codebase
> because doing so would make the result unmergeable to older releases even
> if you later realize that the fix/enhancement would be suitable to them.
>
> And if you fork from older commit than tip, you will automatically get a
> non-ff merge when you merge it back to the mainline, which would delineate
> the history of the side branch from the integration branches rather
> nicely.
>