How Often Are You Fixing Complex Merge Conflicts?
It could be a symptom of bad architecture, process, or coding style.
If you and a colleague change the same line in a file, a merge conflict occurs because Git doesn’t know which code to keep and which to discard: It requires your help to resolve differences between the two commits.
For the rest of this article, I will assume that you already know how to resolve merge conflicts. This article will help you understand the common root causes that merge conflicts happen and how to fix each of them.
Your project does not enforce a coding style.
So your editor replaces all double spaces with tabs whenever you hit save. And now your colleagues are furious!
This scenario is not uncommon. It not only causes merge conflicts, but it will also mess up the git history and make it hard to trace when a change was introduced.
These kinds of issues can be avoided by unifying the coding style within your team; here is how:
Set up an EditorConfig file
EditorConfig helps maintain consistent coding styles across various editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles.
Require linter checks to pass before merging
If you test your code with a continuous integration system that sends build statues back to GitHub, you can avoid complex merge conflicts code by requiring linter checks to pass on a branch before allowing pull requests to be merged.
Examples of code style formatting libraries include standard and ESLint for JavaScript. Black and Pep8 for python
Your project does not enforce good Git practices.
Keeping a clean linear history is essential. In a few months from now, you might want to trace when a feature or a bug was introduced.
If people in your team rewrite the commit history, you’ll find yourself rebasing and fixing merge conflicts quite often.
As with the previous point, an easy fix for this is to protect your project’s base branch and to prevent your team from force pushing.
Other good Git practices that will help prevent complex merge conflicts include writing smaller PRs and commits.
Your team is working on extensive features.
Iz just merged three weeks’ worth of code changes, and now you have to spend your morning trying to understand what she added and how to resolve the conflicts!
This is a fairly common issue, and it’s a process one: The user stories or tickets that you are working on are too big. The solution, in this case, is to discuss with the product owner or project manager how you can split these tickets into smaller stories.
Smaller stories mean smaller features branches with fewer commits.
Splitting a feature into smaller tickets is not always possible: When for example, everything that is merged to master gets automatically released. One solution here is to set up feature flags. Even if a feature is merged to master and released, it won’t be visible to the user until you enable the flag.
Bad ticket or story assignment
A merge conflict can happen if you and your colleague are working on the same parts of code at the same time. Here the problem is caused by poor communication and ticket assignments.
In a new project, it’s quite reasonable that two people are be working on the same components. But for mature codebases, it can be prevented with better communication. Generally, this problem should surface early on either on the planning meeting if your team is using Scrum, in the backlog prioritization meeting if you’re using Kanban, or at least during the standup.
Your project architecture is tightly coupled
Tight coupling is when a group of classes or components are highly dependent on each other.
This happens when a class or component assumes too many responsibilities, or when one concern is spread over many classes rather than having its own class.
This means that even if you’re not working on the same parts of code, you and your colleague might have to update the same component or class, which will cause merge conflicts.
In this case, it’s worth it to review those large classes and components and aim for a loosely coupled architecture. In practice, this can be achieved by applying the single responsibility principle and separation of concerns.
Conclusion
Merge conflicts are a normal byproduct of collaboration, and sometimes can be inevitable. But if they start to cause your team frustration and prevent you from pushing features faster, it’s worth it to dig further and figure out the root cause.
