Getting Started with Git — Chapter 4 / 4

Resolving conflicts

Conflicts can feel scary, but they are completely normal. This chapter teaches you to understand them and resolve them calmly.

Chapter 4 / 4

Step 01 / 09

What is a conflict?

Concept

Keyword: merge conflict A conflict happens when two branches have modified the same part of the same file. Git doesn't know which version to keep. It asks you to choose.

Imagine a shared document. You and a colleague modify the same paragraph at the same time. The software doesn't know which version to keep. It asks you to decide together.

That's exactly what happens with Git. A conflict is not an error. It's Git telling you: "I can't decide for you".

Concept

Key point Git automatically resolves most merges. A conflict only occurs when the same lines have been modified in both branches. If two branches modify different files, or different parts of the same file, Git merges on its own.

Step 02 / 09

When does a conflict happen?

Here's a concrete example:

1

You create a branch from main. The file index.html contains: "Hello".

2

On your branch, you change "Hello" to "Bonjour". You make a commit with this change.

3

Meanwhile, someone changes "Hello" to "Welcome" on main. A commit is made on main with this change.

4

You try to merge your branch into main. Git says: "Conflict! The same line was changed on both sides."

Step 03 / 09

Reading conflict markers

Concept

Keyword: conflict markers When a conflict occurs, Git adds markers in the file. These markers show both versions side by side. They start with <<<<<<< and end with >>>>>>>.

Here's what a file with a conflict looks like:

$ <<<<<<< HEAD The content of your current branch (HEAD) ======= The content of the other branch >>>>>>> feature/header

Each marker has a specific role:

<<<<<<< HEAD — Start of the conflict. What follows comes from your branch (the one you're on).
======= — Separator. It separates the two versions. Above: your branch. Below: the other branch.
>>>>>>> feature/header — End of the conflict. The name after the arrows is the name of the other branch.

In a conflict, which marker separates YOUR changes from the other branch's?

Step 04 / 09

Resolving a conflict: the 4 steps

Resolving a conflict always follows the same steps. Don't panic. Follow this process.

Step 1: See which files are in conflict

Type git status. Conflicting files appear in red with the label "both modified".

$ git status

both modified: index.html

Step 2: Read the file with the markers

Open the file to see both versions. In the simulator, use cat index.html.

Step 3: Write the final content

Remove the markers <<<<<<<, ======= and >>>>>>>. Keep the version you want. You can keep one version, the other, or a mix of both.

$ # In the simulator: echo "<footer>Final version</footer>" > index.html

Step 4: Mark as resolved and commit

Tell Git the conflict is resolved. Use git add to mark the file as resolved. Then make a commit to finish the merge.

$ git add index.html git commit -m "Resolve conflict"

You edited the conflicted file and removed the markers. What next?

Step 05 / 09

Aborting a merge in progress

Concept

Keyword: git merge --abort If you're lost during a conflict, you can cancel everything. The command git merge --abort returns to the state before the merge. Nothing is lost. You can try again when you're ready.

$ git merge --abort

# Cancels the merge in progress
# You go back to the state before
# You can try again whenever you want

Which command cleanly cancels a merge in progress?

Step 06 / 09

How to reduce conflicts

Conflicts are normal. But you can reduce them with a few best practices:

Make small commits — The fewer lines you change, the less likely a conflict. One commit = one action.
Merge often — The longer you wait to merge, the more branches diverge. The more they diverge, the more likely conflicts become.
Communicate with your team — If you know someone is working on the same file, coordinate. It's the best way to avoid surprises.
Split your code into small files — The smaller the files, the less chance two people modify the same one.

Step 07 / 09

Common mistakes

Leaving the <<<<<<< markers in the code. The file won't work with markers in it. You must remove them.
Doing git add + git commit without checking the file contents. Always read the file after resolving the conflict.
Deleting the other person's content without reading it. Take the time to understand both versions before choosing.
Panicking and always doing git merge --abort. It's good to know it exists. But resolving a conflict is an important skill.

Step 08 / 09

Going further

Complete guide: resolving a merge conflict
git rebase: an alternative to merge
git stash: temporarily setting aside your work
Git Confidence Training: the next step

Step 09 / 09

Test your knowledge

Before the exercises, make sure you can resolve a conflict. Pick the answer that looks right.

Quiz — Chapter 4

1. When does a merge conflict occur?

2. What does the ======= marker mean in a conflicted file?

3. After resolving a conflict in a file, what do you do?

4. What does git merge --abort do?

← Chapter 3 You finished all 4 chapters 🎉Final mission & certificate →

Your feedback matters

Help us improve this course by sharing your thoughts.