How to use git reuse recorded resolution (rerere) to merge Git conflicts

When you work on long-living feature branches, you end up in a situation where you have the same conflicts occurring repeatedly.

Here, you can use git rerere, which stands for reuse recorded resolution. Git rerere is not enabled by default, but can be enabled with the following command:

Step 1 : In the jgit repository folder, start by checking out a branch that tracks origin/stable-2.2:

Step 2 : Now, change the maven-compiler-plugin version to something personalized, such as 2.5.2, as this is in line 211 in pom.xml. If you run git diff, you should get a result very similar to the following:

Step 3 : Now add the file and create a commit:

Step 4 : Store your current commit in a backup branch named rerereExample2:

Step 5 : Now, we need to perform the first merge that will fail on auto merge. Then we can solve that. After solving it, we can reuse the merge resolution to solve the same problem in the future:

Step 6 : As we have git rerere enabled, we can use git rerere status to see which files or paths will be recorded:

Step 7 : Edit the pom.xml file (around line 229) and solve the merge conflict so that you can get the diff output shown as follows. You have to remove the line with 3.1 and the merge markers:

Merge markers are lines that begin with <<<<<<, >>>>>>, or ======; these lines indicate the points where Git could not perform an auto merge.

Step 8 : Mark the merge as complete by adding pom.xml to the staging area using git add and then run git commit to finish the merge:

Step 9 : Note the recorded resolution for the pom.xml output from Git; this will not be here without enabling git rerere. Git has recorded this resolution to this particular merge conflict and will also record how to resolve this. Now, we can try to rebase the change to another branch.

Step 10 : Start by checking out the rerereExample2 branch from our repository

Step 11: Try to rebase your change on top of the origin/stable-3.2 branch:

Step 12 : As the merge conflict is the same in pom.xml, Git can solve the conflict in the file for you. This is very clear when you open the file and see there are no merge markers, as the resolution Git had recorded has been applied. Finish the merge by adding pom.xml and continue the rebase:

Step 13 : Start Gitk to see that the commit has been rebased on top of the origin/stable-3.2 branch: