While Git often merges different lines of work automatically, situations arise where it cannot determine the correct way to combine changes. This happens when modifications are made to the same part of the same file on the two branches being merged. Git is smart, but it can't read your mind to know which change is correct or how to combine them. This situation is known as a merge conflict.
Don't worry, merge conflicts are a normal part of working with version control, especially in collaborative environments. Git provides clear signals when a conflict occurs and tools to help you resolve it.
When you attempt a merge (git merge <branch-name>) and Git encounters conflicting changes, it will do the following:
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
<<<<<<<, =======, and >>>>>>>.You can always check which files are currently conflicted by running git status:
git status
The output will clearly list the conflicted files under an "Unmerged paths" section:
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: index.html
no changes added to commit (use "git add" and/or "git commit -a")
Let's look inside a conflicted file, say index.html. You'll find sections marked like this:
<!DOCTYPE html>
<html>
<head>
<title>My Project</title>
<<<<<<< HEAD
<link rel="stylesheet" href="style.css">
=======
<link rel="stylesheet" href="styles/main.css">
>>>>>>> feature-styling
</head>
<body>
<h1>Hi!</h1>
<p>This is the project landing page.</p>
</body>
</html>
Here's how to interpret these markers:
<<<<<<< HEAD: This marks the beginning of the conflicting lines from your current branch (the branch you were on when you ran git merge, often main). HEAD is Git's pointer to the current branch tip.=======: This separator divides the conflicting changes. Everything between <<<<<<< HEAD and ======= is the version from your current branch.>>>>>>> feature-styling: This marks the end of the conflicting lines. Everything between ======= and >>>>>>> feature-styling is the version from the other branch being merged (in this case, feature-styling).Your job is to edit this section to produce the final, correct version and remove the conflict markers.
Resolving a merge conflict involves these steps:
git status to see which files need attention.<<<<<<<.<<<<<<< and >>>>>>> markers until it looks exactly how you want the final version to be.<<<<<<< HEAD, =======, and >>>>>>> feature-styling. Ensure only the desired code remains.
Continuing our example, if we decided the correct path is styles/main.css, the resolved section would look like this:
<!DOCTYPE html>
<html>
<head>
<title>My Project</title>
<link rel="stylesheet" href="styles/main.css">
</head>
<body>
<h1>Hi!</h1>
<p>This is the project landing page.</p>
</body>
</html>
git add:
git add index.html
git status.git status will show that all conflicts are fixed and you're ready to commit. Complete the merge by running git commit.
git commit
If you get into a merge and decide you're not ready to resolve the conflicts, or if things seem too complicated, you can safely abort the merge and return your project to the state it was in before you started the merge. Use the following command:
git merge --abort
This command cleans up the merge state and resets your files, effectively canceling the merge attempt.
Handling merge conflicts might seem intimidating at first, but it's a fundamental skill. By understanding the process and the meaning of the conflict markers, you can confidently integrate different lines of work in your projects. Many text editors and specialized merge tools offer graphical interfaces to assist with conflict resolution, which can be helpful as you gain more experience.
Was this section helpful?
© 2026 ApX Machine LearningEngineered with