Resolving Merge Conflicts

What Is a Merge Conflict?

When Git merges two branches, it usually succeeds automatically by combining changes that affect different lines or different files. A merge conflict occurs when both branches have changed the same lines in the same file in incompatible ways. Git cannot decide which version is correct, so it stops the merge and marks the problem spots for you to resolve manually.

Conflicts are a normal part of collaborative development. Knowing how to resolve them cleanly and confidently is a core professional skill.

How Git Signals a Conflict

When you run `git merge <branch-name>` and a conflict exists, Git prints a message such as:

```

Auto-merging style.css

CONFLICT (content): Merge conflict in style.css

Automatic merge failed; fix conflicts and then commit the result.

```

At this point the merge is paused. Your working directory contains the conflicted file with special markers inserted by Git. Running `git status` will show the file listed under Unmerged paths.

Reading Conflict Markers

Open the conflicted file and you will see a block like this:

```

<<<<<<< HEAD

body { background-color: #ffffff; }

=======

body { background-color: #1a1a2e; }

>>>>>>> feature/dark-theme

```

The three marker lines divide the conflict zone into two sections:

| Marker | Meaning |

|---|---|

| `<<<<<<< HEAD` | Start of your current branch's version |

| `=======` | Divider between the two versions |

| `>>>>>>> branch-name` | End of the incoming branch's version |

Everything between `<<<<<<< HEAD` and `=======` is what your branch says. Everything between `=======` and `>>>>>>> branch-name` is what the incoming branch says.

Resolving the Conflict

Step 1 – Decide on the correct content. You have three options:

• Keep your version (delete the incoming section).
• Keep the incoming version (delete your section).
• Combine or rewrite both into a new version that satisfies the intent of both changes.

The right choice depends on project requirements and team communication. In a professional setting you would discuss with the author of the other branch rather than guess.

Step 2 – Edit the file. Remove the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) and leave only the final, correct content. A file with any marker still present is broken code — never commit it.

VS Code with the GitLens extension highlights conflict markers visually and offers one-click buttons to accept the current change, accept the incoming change, or accept both. These shortcuts edit the file for you, but you must still review the result.

Step 3 – Stage the resolved file.

```

git add style.css

```

This tells Git that you have finished resolving that file.

Step 4 – Complete the merge.

```

git commit

```

Git opens your editor with a pre-filled commit message describing the merge. Save and close to finalize. The merge commit now has two parents, recording exactly where the two histories joined.

Step 5 – Verify.

```

git log --graph --oneline

```

You should see a merge commit (with two parent lines in the graph) at the top of the log. Running `git diff` on the result should show no remaining conflict markers.

Professional Habits Around Conflict Resolution

• Communicate first. If you are unsure why the other branch made a change, ask before resolving. Silently discarding someone else's work causes bugs and erodes trust.
• Document your reasoning. A brief note in the commit message or your lab log explaining why you chose a particular resolution is the equivalent of a code review comment. Future developers (including you) will thank you.
• Test after resolving. A technically clean merge can still break functionality. Load the page or run the relevant tests before pushing.
• Keep merges small. Long-lived branches produce more conflicts. Merging or rebasing frequently reduces the size and complexity of each conflict.

Aborting a Merge

If you become confused mid-resolution, you can safely cancel the entire merge and return to the state before you started:

```

git merge --abort

```

This is always safe to run while a merge is paused. Use it freely during practice.

Safety Note

Version control is the safety net for source code. Never force-push or discard a branch without understanding its history. In a team environment, always confirm with your team lead before rewriting shared history. Treat the `main` or `production` branch with the same care you would treat any critical system — one bad merge deployed to a live server can take a site offline.