Managing Long-Lived Topic Branches with Git Rerere

conflicts when creating the commit marked with `+`. Then you can test the result to make sure your work-in-progress still works with what is in the latest master. After this test merge, there are two ways to continue your work on the topic. The easiest is to build on top of the test merge commit `+`, and when your work in the topic branch is finally ready, pull the topic branch into master, and/or ask the upstream to pull from you. By that time, however, the master or the upstream might have been advanced since the test merge `+`, in which case the final commit graph would look like this: ------------ $ git switch topic $ git merge master $ ... work on both topic and master branches $ git switch master $ git merge topic o---*---o---+---o---o topic / / \ o---o---o---*---o---o---o---o---+ master ------------ When your topic branch is long-lived, however, your topic branch would end up having many such "Merge from master" commits on it, which would unnecessarily clutter the development history. Readers of the Linux kernel mailing list may remember that Linus complained about such too frequent test merges when a subsystem maintainer asked to pull from a branch full of "useless merges". As an alternative, to keep the topic branch clean of test merges, you could blow away the test merge, and keep building on top of the tip before the test merge: ------------ $ git switch topic $ git merge master $ git reset --hard HEAD^ ;# rewind the test merge $ ... work on both topic and master branches $ git switch master $ git merge topic o---*---o-------o---o topic / \ o---o---o---*---o---o---o---o---+ master ------------ This would leave only one merge commit when your topic branch is finally ready and merged into the master branch. This merge would require you to resolve the conflict, introduced by the commits marked with `*`. However, this conflict is often the same conflict you resolved when you created the test merge you blew away. 'git rerere' helps you resolve this final conflicted merge using the information from your earlier hand resolve. Running the 'git rerere' command immediately after a conflicted automerge records the conflicted working tree files, with the usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in them. Later, after you are done resolving the conflicts, running 'git

When working with long-lived topic branches, repeated test merges with the master branch can clutter the development history, and 'git rerere' helps to resolve conflicts in the final merge by reusing previously recorded resolutions, making it easier to manage and keep the topic branch clean.