So you have merge conflict
Merge conflicts — the dreaded words that can send shivers down a developer’s spine. In the world of version control systems like Git, they occur when two or more developers make conflicting changes to the same line of code in the same file, or when one developer deletes a file that another has modified. While they can feel like roadblocks, conflicts are a natural and necessary part of collaborative development, signaling that human intervention is required to decide the “truth” of the codebase.
Instead of fearing them, embrace them as opportunities to integrate changes thoughtfully. A clear resolution strategy is paramount for efficient teamwork and a stable codebase.
Understanding the Anatomy of a Conflict
Before diving into resolution, it’s crucial to understand what a conflict looks like. When Git encounters a conflict during a git merge or git pull, it pauses the operation and marks the conflicting sections in the affected files using special markers:
<<<<<<<<< HEAD
// Your changes from the current branch (HEAD)function sayHello() {
console.log("Hello from feature-A!");
}
=======
// Incoming changes from the branch you are merging
function sayHello() {
console.log("Greetings from feature-B!");
}
>>>>>>> feature-B
These markers delineate the conflicting sections, indicating your changes (<<<<<<< HEAD to =======) and the incoming changes from the other branch (======= to >>>>>>> feature-B).
The Golden Rule: Communicate, Communicate, Communicate!
The single most effective strategy for resolving conflicts, especially complex ones, isn’t technical — it’s communication. Before you even touch a keyboard, if the conflict is significant or affects core logic, talk to the other developer(s) involved.
• Why? They understand their changes best. A quick conversation can clarify intentions, identify unnecessary changes, and lead to a consensus on the correct merged code far faster than guessing.
• When? Immediately after detecting a significant conflict.
Of course! Merge conflicts are an unavoidable part of collaborative software development, especially when multiple developers are working on the same codebase simultaneously. While they can be frustrating, having a clear strategy for resolution is key to maintaining productivity and code integrity.
1. Manual Resolution (The Most Common)
For most day-to-day conflicts, you’ll resolve them manually using your code editor or an IDE’s built-in merge tool.
• Process:
• Git will stop the merge and mark the files.
• Open the conflicted file in your editor.
• Carefully examine the <<<<<<<, =======, and >>>>>>> markers.
• Decide:
• Take “Yours”: Delete the =======, >>>>>>> lines, and the incoming changes.
• Take “Theirs”: Delete the <<<<<<<, ======= lines, and your changes.
• Combine: Integrate parts of both changes, modifying the code to correctly incorporate both intentions. This is often the most common scenario.
• Remove all conflict markers (<<<<<<<, =======, >>>>>>>).
• Save the file.
• Once all conflicts are resolved and markers removed, git add
• Finally, git commit to complete the merge.
• Best For: Smaller, localized conflicts, changes that are easy to understand from context, and when you clearly prefer one version over the other.
2. Using Git’s Built-in Merge Tools
Git comes with several command-line tools and can integrate with external visual merge tools (like Meld, KDiff3, Beyond Compare).
• git mergetool: After a conflict, running git mergetool will launch your configured visual merge tool. This tool typically provides a three-way view: your version, their version, and a base common ancestor version. It offers a graphical interface to pick changes, combine lines, and save the result.
• Best For: Medium to large conflicts, when visual comparison is easier, or when you need the context of the common ancestor.
Strategic Conflict Handling with Git Commands
Sometimes, you don’t want to manually merge but want to strategically choose one branch’s version for an entire file or even revert the merge.
• git checkout --theirs
• Caution: This takes the entire file from the other branch.
• git checkout --ours
• Caution: This takes the entire file from your current branch.
When Nothing works
These are the sequence of steps that I apply, this is most straight forward and fool proof in scenarios when developers work in different time zones. You don’t have direct access of context. Or you are working on large codebase.
1. Checkout source branch at new location
2. Get the changes from the source branch.
3. Now you have latest of the branch, super impose your changes on top of it as you know your changes better than anyone’s else changes.
4. Test out and check-in with your changes.
5. There are chances that when you modified block code, you have made changes on the basis of the state of file of that time but new state either moved stuff entirely or added new logic. So always ensure step is done post super imposition.
6. AI is not yet good at step 5 so be aware of using co-pilots for these things since it cannot read your mind but only codebase :).
What to read next
The Candidate Dropout Problem You Didn’t Know About.