What happens when Git finds a merge conflict

A merge conflict happens when you try to combine two branches and Git cannot automatically decide which version of a line to keep. This occurs when both branches changed the same part of the same file in different ways. Git stops the merge, marks the conflicting sections in your files, and waits for you to choose which changes to keep.

The conflict markers appear as special text in your file: <<<<<<< marks the start of your current branch's version, ======= separates the two versions, and >>>>>>> marks the end of the incoming branch's version. Your job is to remove these markers and decide what the final code should look like.

Conflicts are normal and not a sign that something went wrong. They simply mean Git needs a human to make a decision about which changes matter more, or how to combine them both.

Key Takeaways

  • Merge conflicts appear as marked sections in your files showing both versions of the conflicting code, and you must manually choose or combine them.
  • Use git status to see which files have conflicts, then open each one in your editor to find the conflict markers and decide what to keep.
  • After you fix the conflicts, stage the files with git add, then complete the merge with git commit.
  • If a merge goes wrong, you can undo it entirely with git merge --abort and start over without losing any work.
  • Conflicts happen most often when multiple people edit the same lines, so keeping changes focused and communicating with your team reduces them.

Finding which files have conflicts

When a merge conflict occurs, Git stops and tells you. Run git status to see the list of files with conflicts — they appear under a section called "both modified" or similar, depending on your Git version. The status output also shows files that were changed only on one branch, which Git merged automatically.

Open your editor or IDE and navigate to each conflicted file. The conflict markers are plain text, so you can see them in any editor. Look for the <<<<<<< and >>>>>>> markers — they stand out visually and mark exactly where the problem is.

Resolving conflicts by choosing one version

The simplest conflict is one where you want to keep either your version or the incoming version entirely, with no mixing. Find the conflict markers in the file. Your current branch's code is between <<<<<<< HEAD and the ======= line. The incoming branch's code is between ======= and >>>>>>>.

Delete the version you do not want, then delete all three marker lines. If you want to keep only your version, delete everything from ======= to >>>>>>> inclusive, plus the <<<<<<< HEAD line. If you want the incoming version, delete everything from <<<<<<< HEAD to ======= inclusive, plus the >>>>>>> line. What remains is the code you chose.

Combining both versions to resolve the conflict

Sometimes the right answer is to keep changes from both branches. This happens when each branch added different things, or when you need to merge logic from both sides. Read both versions carefully and decide what the final code should do.

Edit the section between the conflict markers to include the parts you need from both versions. You might keep lines from the first version, add lines from the second, reorder them, or rewrite the section entirely to incorporate both changes. The goal is to make the code work correctly with both sets of changes applied.

Once you have written the final version, delete all the conflict markers: <<<<<<< HEAD, =======, and >>>>>>>. The file should now contain only the resolved code with no marker lines remaining.

Finishing the merge after resolving conflicts

After you fix all the conflicts in all the files, tell Git that the conflicts are resolved. Run git add on each file you fixed, or run git add . to stage all modified files at once. This tells Git that you have resolved the conflicts in those files and they are ready to be committed.

Then run git commit to complete the merge. Git opens your editor to let you write a commit message. You can accept the default message (which mentions the merge) or write your own. Save and close the editor, and the merge is done. Your branch now contains all the changes from both sides.

Undoing a merge if something goes wrong

If you start a merge and realize you made a mistake, or the conflicts are too complicated to handle right now, you can undo the entire merge without losing any work. Run git merge --abort and Git will stop the merge and return your files to the state they were in before you started.

This is safe to do at any point during the merge process, even after you have started fixing conflicts. No changes are lost — your working directory goes back to normal, and you can try the merge again later or take a different approach.

Using tools to help with complex conflicts

For conflicts that are hard to understand by reading the markers, you can use a merge tool — a visual program that shows both versions side by side and lets you click to choose which parts to keep. Most editors and IDEs have built-in merge conflict resolvers. Visual Studio Code, for example, shows "Accept Current Change", "Accept Incoming Change", and "Accept Both Changes" buttons directly above each conflict.

If your editor does not have a built-in tool, you can configure Git to use an external merge tool like Meld, KDiff3, or Araxis. Run git config --global merge.tool [toolname] to set your default, then run git mergetool when a conflict occurs. The tool opens and guides you through each conflict visually.

Preventing conflicts before they happen

Conflicts are easiest to avoid by keeping branches focused and short-lived. If each branch solves one specific problem and stays open for only a few days, the chance that two branches will edit the same lines drops significantly. Long-running branches that diverge far from the main codebase are much more likely to have conflicts when they finally merge.

Communicate with your team about who is working on what. If two people know they are both editing the same file, they can coordinate — one person finishes and merges first, then the other pulls the latest changes before starting their work. Code review before merging also catches potential conflicts early, when they are easier to discuss and resolve.

Frequently Asked Questions

What if I see a conflict in a file I did not edit?

Git marks a conflict whenever the same lines changed on both branches, even if you did not make those changes yourself. This usually means someone else on your team edited those lines on your current branch while you were working on the incoming branch. You still need to resolve it by choosing which version is correct or combining them.

Can I see what the file looked like before the merge started?

Yes. Run git show :1:filename to see the common ancestor version (the version both branches started from), git show :2:filename to see your current branch's version, and git show :3:filename to see the incoming branch's version. This helps you understand how each side changed the code.

What if the merge tool shows three versions instead of two?

The three versions are the common ancestor (what both branches started with), your current version, and the incoming version. The ancestor helps you see what each branch changed, making it easier to decide which changes to keep or how to combine them.

Do I have to resolve all conflicts at once?

Yes, you must resolve all conflicts before you can complete the merge. However, you do not have to do it in one sitting. You can fix some conflicts, run git merge --abort to undo, take a break, and start the merge again later. Your work is not lost — Git only saves changes you have committed.

What happens if I push a merge with conflicts still in the file?

You cannot push a merge with unresolved conflicts. Git will not let you commit until all conflicts are resolved and the conflict markers are removed. If you somehow committed with markers still present, the code would be broken and your team would see the markers when they pull your changes.