Avoid 80% of Git merge conflicts
...and make the rest trivial.
Afraid of merge conflicts or know someone who is? This post will share a way to handle merging branches so you never have to worry about merge conflicts again.
Git is like making a sandwich
Every time you make a commit to git, it adds your commit to the top of a pile of commits, like adding a slice of meat or cheese to the top of a sandwich. This pile of commits never topples over, no matter how tall it gets.
Order is important to this pile, as with a sandwich. You wouldn’t make a sandwich with all the bread sitting on top, right? If you would, that’s OK. I won’t judge. But order is still very important. Git merge and rebase are all about ordering your commits.
When you have a merge conflict, it’s like not knowing which slice goes first, the cheese or the bread. Sometimes Git will try to figure it out automatically, and other times it’s scared of messing things up and asks you for help. It’s annoying in the moment, but it’s better than a messed up sandwich.
Disclaimer
Technically, git merge is more than just piling code on top of more code. It actually looks through the pile for the last common commit between the two branches, and then tries to combine them from there. But if you follow the following method, you won’t need to worry about that, because this method will make sure that last common commit is always right on top. That way you get the nice sandwich effect.
There are only two scenarios
Most of the time, you will either be putting changes from your branch into master, or you’ll be putting changes from master into your branch.
The trick to avoiding merge conflicts is each time you have to put code from one branch into another, you just gotta figure out which of these two scenarios you are in.
Merge my-branch onto master
Say you are on master (and you’ve already run git pull), and you run…
git merge my-branchGit is putting the changes from your branch on top of master.
Rebase master onto my-branch
Say you are on my-branch, and you run…
git rebase masterGit is taking off the changes you made on my-branch, then it is putting the latest changes from master, and finally it puts your changes from my-branch back on top. It’s like the second frame of the sandwich-making GIF above, when the top slice of bread is removed. After that, the meat and cheese are added, and then the top slice is put back on top of the whole pile. That’s what git rebase does.
The steps
In order to get the nice sandwich effect, where you’re just adding code to the pile and never getting a conflict, there are a couple steps you must follow.
First, make sure to git pull the latest changes into master.
Second, git rebase master into your branch. This will likely be the only time you get a conflict, and it should only be because someone else has changed the same code as you since the last time you rebased master, so it’s usually very easy to fix.
Do these first two steps often. At least once a day, if you’re branch lives that long.
Finally, whenever you want to merge your branch with master, make sure you do the first two steps right before, and then finally from master you can run git merge my-branch. Since your branch is totally up-to-date with master, Git will simply put your code on top of the master pile. Voila!
