What is a Merge Conflict?
A merge conflict occurs when you try to merge two branches that have competing changes. Git is unable to automatically decide which change to keep. This typically happens when the same line of code in the same file is modified on both branches.
When a conflict happens, Git pauses the merge process and waits for you to resolve the conflict manually.
Problem Scenario
Letโs say you have a main branch and a feature branch. Both branches have changes in the same file, style.css.
On the main branch, style.css was changed to:
body {
color: #333;
font-family: Arial, sans-serif;
}
On the feature branch, style.css was changed to:
body {
color: #444;
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
}
When you try to merge feature into main:
git switch main
git merge feature
You will see an error message:
Auto-merging style.css
CONFLICT (content): Merge conflict in style.css
Automatic merge failed; fix conflicts and then commit the result.
Solution
1. Identify Conflicting Files
Git tells you which files have conflicts. You can also use git status to see a list of unmerged paths.
git status
On branch main
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: style.css
no changes added to commit (use "git add" and/or "git commit -a")
2. Open and Edit the File
Open style.css in your code editor. Git marks the conflicting areas:
body {
<<<<<<< HEAD
color: #333;
font-family: Arial, sans-serif;
=======
color: #444;
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
>>>>>>> feature
}
<<<<<<< HEAD: This marks the beginning of the conflicting change from your current branch (main).=======: This separates the two conflicting changes.>>>>>>> feature: This marks the end of the conflicting change from the branch you are merging (feature).
3. Resolve the Conflict
You need to decide what the final version should look like. You can choose one version, the other, or a combination of both.
Letโs say we want to keep the font-family from the feature branch and the color from the main branch. Edit the file to look like this:
body {
color: #333;
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
}
Make sure to remove the conflict markers (<<<<<<<, =======, >>>>>>>).
4. Stage the Resolved File
After you have resolved the conflict in the file, you need to tell Git that the conflict is resolved by staging the file.
git add style.css
5. Commit the Merge
Once all conflicts are resolved and the files are staged, you can complete the merge by creating a merge commit.
git commit
Git will open an editor with a pre-populated commit message like โMerge branch โfeatureโโ. You can keep it as is or modify it. Save and close the editor to create the commit.
The merge is now complete.
Aborting a Merge
If you get into a complicated merge and want to start over, you can always abort the merge process.
git merge --abort
This will return your branch to the state it was in before you started the merge.
Conclusion
Merge conflicts are a normal part of working with Git. By understanding what the conflict markers mean, you can resolve them confidently. Always review the changes carefully to ensure the final result is correct.
Professional Depth Check
For How to Resolve Merge Conflicts in Git, the practical standard is not whether the reader can repeat one instruction once. Treat the topic as a reproducible debugging procedure: verify repository root, branch and remote state, index and working tree, and credential or network boundary before drawing a conclusion. The result should be written as a small decision record, because future readers need to know which fact was observed, which assumption was used, and which condition would change the answer.
Evidence That Makes the Guidance Reliable
Use objective evidence before changing a workflow. Good evidence includes git status, git remote -v, git branch --show-current, and the exact command that failed. If two pieces of evidence conflict, keep the conflict visible instead of smoothing it over. For example, a successful quick fix is still weak evidence if the same input, account, dependency, or device state has not been tested again. A durable article should help the reader distinguish a confirmed fix from a plausible fix.
Review Table
| Review Item | What To Confirm | Why It Matters |
|---|---|---|
| Scope | The exact case covered by this article | Prevents over-applying the advice |
| Baseline | The state before any change | Makes rollback and comparison possible |
| Change | The smallest action taken | Reduces hidden side effects |
| Result | The observed output after the change | Separates evidence from expectation |
| Recheck | When to revisit the conclusion | Keeps the post accurate over time |
Edge Cases and Failure Modes
The main risks are fixing the symptom while leaving the root cause, and mixing unrelated changes into the same test. When the situation involves production data, personal information, money, health, legal rights, or security recovery, the conservative path is to stop and collect evidence before applying a broad fix. The same title can describe very different cases, so the reader should compare their environment with the assumptions in the post before copying commands or decisions.
Maintenance Standard
Recheck this guidance after dependency, operating-system, or build-tool changes. A useful update does not need to rewrite the entire post; it should confirm whether the examples, links, commands, screenshots, and decision criteria still match current behavior. If the old conclusion remains valid, record the check date. If it changes, explain what changed and why the previous advice is no longer enough.
Related Reading
Continue with these related posts from the same topic area.
Leave a comment