Conflict Resolution

When Timelines Collide

Sometimes two branches change the same lines of the same file. When you try to merge them, Git can't decide which version to keep, so it stops and asks you to choose. That pause is a merge conflict—a timeline collision that needs a human navigator.

Conflicts are normal. They aren't errors, and they don't mean anyone did something wrong. They simply mean two crew members edited the same code, and Git needs you to choose the final version.

When Conflicts Happen

• Two branches edit the same lines of a file
• One branch deletes a file that another branch modified
• Both branches add a file with the same name but different contents

If the changes touch different lines or different files, Git merges them automatically—no conflict at all.

Spotting a Conflict

git merge feature-branch

When a conflict occurs, Git reports it clearly:

Auto-merging navigation.js
CONFLICT (content): Merge conflict in navigation.js
Automatic merge failed; fix conflicts and then commit the result.

Run git status to list every conflicted file under "Unmerged paths".

Reading Conflict Markers

Git marks the conflicting region in the file:

<<<<<<< HEAD
const speed = 'warp 9';
=======
const speed = 'impulse power';
>>>>>>> feature-branch

• <<<<<<< HEAD: your current branch's version
• =======: the divider between the two versions
• >>>>>>> feature-branch: the incoming branch's version

Resolving Step by Step

1. Open each conflicted file
2. Decide what the final code should be—keep one side, the other, or combine both
3. Delete all conflict markers (<<<<<<<, =======, >>>>>>>)
4. Stage the resolved file: git add navigation.js
5. Complete the merge: git commit

# After editing the file
git add navigation.js
git commit

Git pre-fills a merge commit message—you can accept it as-is.

Aborting a Merge

Not ready to resolve right now? Back out safely:

git merge --abort

This returns your branch to the state it was in before the merge started.

Using Visual Tools

Editors like VS Code highlight conflicts and offer one-click Accept Current Change, Accept Incoming Change, or Accept Both buttons. For complex conflicts, a visual diff makes the decision much easier.

Preventing Conflicts

• Pull the latest changes before starting new work
• Keep branches short-lived and merge often
• Split work so crew members touch different files
• Communicate with your crew about who is editing what

Common Mistakes

• Leaving stray markers: Forgetting to delete <<<<<<< or ======= breaks the build silently—always re-read the file before committing.
• Resolving blind: Picking a side without understanding what the other branch was trying to do. When in doubt, ask the author or check git log -p on both sides.
• Force-pushing over an unfinished merge: If you're unsure, run git merge --abort and start again rather than guessing.

Next: Mission Corrections

You can now resolve timeline collisions with confidence. Next, learn how to undo mistakes in Git with resets, reverts, and amended commits.