Question

I was reading this blog post on git which talks about various branching strategies. The article recommend that for long lived feature branches one should keep merging from master into the feature branches to keep the feature branch in sync with master so that when feature branch gets merged back into master it won’t be problematic. This strategy is clear to me. In comments Junio Hamano the git mainter says.

I would have to caution that “branch out and sync often” is a
disease to be avoided. You branched to achieve a specific goal (e.g.
“add this feature”, “fix this bug”) and the point of having a
dedicated branch for that task is to keep the history of that
particular branch readable and understandable, which will lead to less
bugs. It will defeat the point of using a separate branch if you
randomly merge back from “master” at the point where the work on your
branch is not yet ready, and whatever was done on “master” does not
affect what the specific goal of adding the feature or fixing the bug.

The standard recommendation to avoid the disease, while making sure
that the time-consuming work you are doing on your branch that was
forked while ago still does work well with the random work done by
others, is to make a throw-away “test” branch that merges from your
topic branch and the master branch to keep the codebase-drift in
check.

My question how does throw-away test branch strategy work, how does it make the final integration with master easier? Can anyone provide a more detailed example / easier to understand explanation?

Answer 1

I found the detailed explanation of this pattern at Junio Hamano’s blog Fun with ReReRe .

The basic idea is to do a test merge on a branch that will not be kept and then use the rerere feature of git to record how conflicts are resolved then, throw away the test merge branch, and when final merging occurs the recorded merge resolutions will be automatically applied by git.