Lab: Resolve a Merge Conflict

Time15 minutes

LevelBeginner

You needLocal Git only — no GitHub account needed

Scenario

Two people edited the same lines of the same file on different branches. Merging one into the other, Git stops and reports a conflict.

A conflict is not an error. It is Git declining to guess which change is correct — because it cannot know.

Objective

Create a genuine conflict, read the markers correctly, resolve it, and know how to abort when a resolution has gone wrong.

Prerequisites

• Git installed
• Comfortable with git commit and git switch
• Git Merge provides the model this lab exercises

Starting state

mkdir -p /tmp/lab-conflict && cd /tmp/lab-conflict
git init -q .
git config user.email "lab@example.com"
git config user.name "Lab User"

cat > config.js <<'EOF'
export const config = {
  timeout: 3000,
  retries: 3,
  endpoint: "https://api.example.com",
};
EOF
git add . && git commit -q -m "Add config"

# Branch A: the performance work
git switch -qc perf/timeouts
sed -i 's/timeout: 3000/timeout: 500/' config.js
git commit -qam "Reduce timeout for faster failure"

# Branch B: the reliability work, on the same line
git switch -q main
sed -i 's/timeout: 3000/timeout: 10000/' config.js
git commit -qam "Raise timeout for slow networks"

git log --oneline --all --graph

Two branches. Both changed timeout. Both are defensible. Git will not choose.

Tasks

1. Trigger the conflict:

   git merge perf/timeouts

   Expected: CONFLICT (content): Merge conflict in config.js and Automatic merge failed; fix conflicts and then commit the result.

2. Inspect the state. Run git status. Note that config.js is listed under “Unmerged paths” — it is neither staged nor unstaged, but in a third state.

3. Read the file:

   cat config.js

   Identify which side is which. HEAD is the branch you are on — main, with the 10000 value. The other side is what you are merging in.

4. Resolve it. Edit config.js so it contains exactly one timeout line and no conflict markers. For this lab choose 10000, the value that handles slow networks.

5. Verify no markers remain:

   grep -nE '^(<<<<<<<|=======|>>>>>>>)' config.js && echo "MARKERS REMAIN" || echo "clean"

6. Stage and commit:

   git add config.js
   git commit --no-edit

7. Now practise aborting. Reset and redo the merge, then abandon it:

   git reset --hard HEAD~1
   git merge perf/timeouts
   git merge --abort
   git status

   Confirm you are back to a clean tree with no merge in progress.

Practice Mode (in your browser)

Educational Git simulator. Supports the commands needed for this exercise; it is not a complete Git installation. Nothing runs on your machine and nothing is sent anywhere — progress is kept in this browser only.

Objective: Merge `perf/timeouts` into `main`. Both branches changed `timeout` in `config.js`. Resolve the conflict keeping 10000 (the value that handles slow networks), then complete the merge. Estimated 8 minutes. Hints, a worked solution and a restart are available; success is checked against the repository state, so any correct route counts.

Open Practice Mode

Loading the simulator…

Hints

What do the markers mean?

<<<<<<< HEAD
  timeout: 10000,        ← your current branch
=======
  timeout: 500,          ← the branch being merged in
>>>>>>> perf/timeouts

Resolution means producing the correct final content. It does not have to be either side — it can be both, neither, or something new. Git only requires that the markers are gone.

git diff during a conflict shows a combined diff against both parents, which reads oddly the first time. git diff --ours and git diff --theirs are usually clearer.

Taking one side wholesale:

git checkout --ours config.js     # keep current branch's version
git checkout --theirs config.js   # take the incoming version

Solution

git merge perf/timeouts
# CONFLICT (content): Merge conflict in config.js

cat > config.js <<'EOF'
export const config = {
  timeout: 10000,
  retries: 3,
  endpoint: "https://api.example.com",
};
EOF

grep -c '<<<<<<<' config.js    # 0
git add config.js
git commit --no-edit
git log --oneline --graph

Aborting instead:

git merge --abort

Explanation

Git merges by three-way comparison. It looks at the merge base (the last common commit) and both tips. Where only one side changed a region, that change is taken automatically. Where both sides changed the same region differently, there is no correct automatic answer — so Git writes both versions into the file and stops.

Conflict markers are a working state, not corruption. The file is deliberately invalid so that committing it accidentally is hard.

The index tracks the conflict. During a conflict the index holds up to three versions of the file — base, ours, theirs. git add collapses them to your resolution, which is why staging is what marks a conflict resolved.

git merge --abort is always available while unresolved. It restores the pre-merge state exactly. After the merge is committed you need git revert -m 1 <merge-sha> instead.

Caution

The dangerous resolution is one that removes the markers but silently drops one side’s intent. Deleting the conflicting block resolves the conflict and loses a change nobody notices until it matters. After resolving, read the whole region — not just the lines that had markers.

Clean up

cd /tmp && rm -rf lab-conflict

Related lessons

Resolving Merge ConflictsThe full treatment, including multi-file conflicts.

Git MergeHow three-way merging works.

Fast-Forward vs Three-WayWhy some merges never conflict.

Git TroubleshootingA decision tree for conflicts and other trouble.

Next lab

Repair a broken interactive rebase — the same conflict skills, under the harder conditions rebase creates.