4 Simple Tricks to Avoid Merge Conflicts

Git is a great tool if you have multiple developers working on the same code base. However, there is one thing which can be very annoying if your team uses Git: Merge conflicts! Two developers have changed the same part of the code and then Git doesn’t know what to do. Fortunately, there are a few tricks to avoid merge conflicts and this article will tell you how!

Trick #1: Short-Living Branches

Many big merge conflicts are results of long-living branches. If you work in your own branch for several days, or even weeks, the risk is high that someone else changes parts of the code you have touched in another branch. That would lead to merge conflicts. On the other hand, if you have a short-living branch, meaning it is merged back into the trunk or master branch after a few hours, there will probably be no merge conflict. Even if there is a conflict, it can usually be resolved very quickly because there is much less code to think about.

The following figures both show a master branch (the line in the middle) and some kind of feature branches. The difference between those figures is that the first one contains many short-living branches while the second one has only two long-living feature branches. The merge commits in the first figure are always green because the short branches have not caused any merge conflicts. In the second figure we have a red dot at the end which represents a merge conflict that was caused by two of the many commits in the long-living branches.

Short Living BranchesLong Living Branches

Trick #2: Small Modules

Small DocumentsThe Single Responsibility Principle (which is part of the SOLID principles of software design) says that “a class should have one, and only one, reason to change“. If we take this approach serious, there should never be a situation in which two developers change the same code at the same time because that would mean they are working on the same task. You see, a modular architecture and small classes do not only help to increase the quality of the code design but also decrease the chance for merge conflicts.

Trick #3: Strong Communication

Communication“Communication is the key” – We have heard this phrase so many times… and it’s true! If all your team mates know what you are working on and which parts of the code you are touching they will try not to change the same code at the same time. If another developer wants to change a part of the code base which you are working on then it would probably be a good idea to work together which leads me to the fourth trick…

Trick #4: Mob Programming

Mob ProgrammingThis trick is the most powerful of all because it can eliminate merge conflicts completely! Mob Programming means that the whole team is working together on the same computer. That makes merge conflicts impossible because the whole mob is working on the same branch.

This is how branching would typically look like with Mob Programming:

Mob Programming Branch


Do you know more tricks to avoid merge conflicts? I would really like to know them so feel free to write a comment!

10 thoughts on “4 Simple Tricks to Avoid Merge Conflicts

  • Pingback: From Git Flow to Trunk Based Development

  • Pingback: 4 Simple Tricks to Avoid Merge Conflicts – The Team Coder | Git Tips

  • Pingback: From Git Flow to Trunk Based Development

  • May 26, 2017 at 12:15 am

    Regarding “Short-living branches” … what you suggests seems to have little to do with the lifetime of the branch, and instead *everything* to do with how frequently you merge/commit changes. Whether you use a branch or not, the key is breaking up work into smaller, testable chunks, and working on them one at a time, in sequence, merging after each one.

    That would seem to suggest something more along the lines of TDD or BDD (independently of whether or not you use a (story-)branch while making those changes).

  • Pingback: Git und die Merge-Konflikte | trollheaven

  • April 13, 2019 at 4:10 am

    Is merging a seriously problem? Different compare/ merge tool(such as winmerge and Beyong Compare in Windows) are good to resolve merging issues.

    • April 13, 2019 at 9:37 am

      At least it can quickly get a very annoying task, in my experience. It’s simpler for code files but can become a nightmare for big configuration files. And the more merge conflicts you get the higher is the risk of breaking something.

      Does it always work out smooth for you? Which programming language and technologies do you use?

  • April 14, 2019 at 5:51 am

    “big configuration files”. May be too many feature toggles :)
    You could split configuration file info a few smaller “per feature” config files.
    Developers should follow “Single Responsibility Principle” and communicate when working in the same area, but it has much more benefits, than just reduce chance of merge conflicts. In new projects we are using microservices , that separate work between different teams/developers and make merge conflicts unlikely to happen

    • April 14, 2019 at 10:10 am

      You are right, avoiding merge conflicts is only a nice side effect if you apply those 4 tricks. There is much more behind it ;-) All the 4 things pay into the bigger goal of truly agile development :-)

  • Pingback: Why modules in Puppetfile should be sorted – PUPPETEERS OY

Leave a Reply

Your email address will not be published. Required fields are marked *