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?
Handling Conflicts When Rebasing For example, if on main someone edited the same file and line you did on your branch. The same thing happens when merging. We have two conflicting states, and we want to resolve them by changing the file to the version that incorporates the changes correctly.
Because of at least two reasons: Rebasing changes the commit IDs (i.e. the SHA-1 hashes of their metadata). This means that once you push the rebased commits to the shared branch, they will appear as completely new commits to anyone that fetches them on their local repo, even if they still contain the same changes.
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:
... but essentially you can just do:
git config --global rerere.enabled 1
... and forget about it, while enjoying easier rebasing / merging :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With