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?

Solution 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 :)

Solution 2

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).

Solution 3

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.