How to prevent many git conflicts when rebasing many commits?

Question

Story: in the middle of a project my colleague created a new branch from master and started doing her heavy re-factoring work. I created my branch from master and started doing new stuff on the page. We are committing regularly, but only I can rebase code to master (because colleagues changes are too heavy and cannot be deployed from master yet). Unfortunately some of our work rely on the same files. So after few days of work when she finally wanted to rebase her changes to master, she had a lot of git conflicts.

my_branch    #---#----#-#-------#----#--#-----#---#----#----#
            /     \              \   \   \              \    \
master     *-------*--------------*---*---*--------------*----*----*
            \                                                     /
her branch   #------#-------#-----------#-----------#------------#

Question 1 is: how to prevent lot of git conflicts when we are working on same files? (or what is the best practice in this situation?)

but this isn't the end of our question, ...to be absolutely correct she tried to do rebase from master to her branch (to have changes I committed), so the commit map should look something like this

my_branch    #---#----#-#-------#----#--#-----#---#----#----#
            /     \              \   \   \              \    \
master     *-------*--------------*---*---*--------------*----*----*
            \                   \            \                    /
her branch   #------#-------#----*------#-----*-----#------------#

And this is what is bothering us. During these rebases she was fixing those conflicts. But git doesn't remember her decision on conflict fix, so when she did another git rebase from master to her-branch she had to fix the same git conflicts again that she was fixing in previous rebases.

Question 2 is: how to tell git to remember git conflict fix after git rebase from master branch, so after next rebase we don't have to fix the same conflicts again?

Answer 1

Fortunately, git has a mechanism for dealing with exactly this problem called git rerere - essentially, if you have git rerere enabled, then each time your resolve a conflict the fact that you resolved that exact conflict in a particular way is remembered. If the same conflict comes up again, the same resolution is automatically used. There are some helpful articles below:

• http://scottchacon.com/2010/03/08/rerere.html (blog post)
• http://git-scm.com/docs/git-rerere.html (manual entry)
• Are there any downsides to enabling git rerere? (question in stackoverflow)
• http://progit.org/2010/03/08/rerere.html (original answer link: seems broken)

... but essentially you can just do:

git config --global rerere.enabled 1

... and forget about it, while enjoying easier rebasing / merging :)

Answer 2

Let me share one possible way to resolve rebase conflicts. I call it rebase via merge. It can help if you want to rebase a branch with many commits and many conflicts are expected.

First, let's create a temp branch and force all conflicts to show up with a regular merge

git checkout -b temp
git merge origin/master

Resolve all the conflicts the regular way and finish the merge.

So temp branch now shows how the project should look like with all the conflicts resolved correctly.

Now let's checkout your untouched branch back (let it be alpha).

git checkout alpha

And do a rebase with mechanical conflict auto-resolution in favor of current branch.

git rebase origin/master -X theirs

The project code can be broken or invalid at this moment. That's fine, the last step is to restore the project state from temp branch with a single additional commit

git merge --ff $(git commit-tree temp^{tree} -m "Fix after rebase" -p HEAD)

Basically, this step uses a low-level git command to create a new commit with exact same project state (tree) as in temp branch. And that new commit is being merged immediately.

That's it. We just did a rebase via hidden merge. And temp branch can be deleted.

git branch -D temp

Also, there is a script to do the same thing interactively. It can be found here.

Answer 3

Make sure that you are always rebasing using the --onto switch.

To prevent conflicts, use floating development branches. Each developer will continuously rebase their development branch. This is easy since the developer knows what he just implemented and shouldn't have problem with solving conflicts. Instead of rebasing, just merge the final version (it will already be rebased).

Answer 4

You can squash her branch to prevent Successive conflict resolving. when you squash all commit in her branch after creating from master into one commit, then conflict can be resolve in one step.

If you want to write the new commit message from scratch, this suffices:

git reset --soft HEAD~3 &&
git commit

In this example, we'll squash the last 3 commits.

To prevent this problem in the future, I recommend you to rebase your branch with source branch after each commit.

Answer 5

If 2 devs made different changes to the same line of code, conflicts will be unavoidable, as git will not know which like it should keep or discard.

As for rebase from master, this is really not the ideal practice unless you want to deliberately change the commit history (and possibly change the commit history of your colleague).

From the official documentation about rebasing:

Do not rebase commits that exist outside your repository and that people may have based work on.

You should be using git merge instead.

Answer 6

I do not use rebase anymore for anything other than simple use cases. cherry-pick is almost always easier to use and requires a simpler mental model. The most complicated thing with cherry-pick is sometimes you need to create a new clean branch and apply the cherry-pick commits there.