Git Tricks: Avoid solving the same rebase conflict multiple times

Rebase is one of the main ways to integrate changes from one git branch to another. It consists of placing all commits of a source branch on top of the target branch. Its basic usage is simple:

$ git checkout new-branch
$ git rebase main

As complexity grows, branches will be created from other branches and, when rebasing onto an already rebased branch, you may be asked to solve the same conflicts you solved in the first rebase. To understand why this happens, it’s important to know that using rebase changes the hash of the affected commits. Because of this, git assumes it’s a different thing and doesn’t know that the conflict has already been solved in the past.

Before rebase
*--a--b—--d -> A
    \---c---e-----g -> B
             \-f-----h---i -> C
After rebasing B onto A
*--a--b—--d -> A
    \      \---c'---e'-----g' -> B
     \---c--e--f---h---i -> C
After merging B onto A
*--a--b—--d---c'---e'-----g' -> A
    \---c--e--f---h---i -> C 

Note that all commits on Branch B changed to a commit' version. It represents the same change, but with a different hash.

If when rebasing B to A you solve a conflict on c, when rebasing C to A, git will not recognize that c is already rebased and will try to put it on top of g', prompting you to solve the conflict again. In complex cases, with a lot of commits and conflicts, this could lead to a lot of extra work.

To solve this problem, we have two options.

Using git rerere functionality

“rerere” stands for “reuse recorded resolution”. It’s a flag that, when active, tells git to record how you solve each conflict to reuse it in case you need to solve it again. Turning it on is super simple:

$ git config --global rerere.enabled true

And it’s done. From now on, every time you would be asked to solve a conflict you’ve already handled, you won’t. Git will identify the recorded conflict and solve it for you.

It’s important to note that git rerere will record only future conflicts, but if you landed here while searching for “solving the same conflict multiple times” you probably already have this situation going on. Which leads us into our second option:

Using git cherry-pick

This is not as simple as using rerere but it’s still simple. With cherry-pick we can select a range of commits to apply to a given branch. This way, we can make a “manual rebase”, selecting only the commits that were not rebased onto the first one.

In our example situation, we’ll need to select commits f, h and i from branch C and put them on top of branch A:

$ git checkout A
$ git cherry-pick f^..i

And it’s done.

Want to learn more about Git and other stuff related to development? Follow our blog Goiabada and enjoy a delicious mix of software development, design, and business.