Lesson 01 of 05Concept

Why Conflicts Happen

Goal: Understand when Git can merge on its own, and when it needs you to decide.

Git merges what it can

In a three-way merge, Git compares each file in three versions: the merge base both branches started from, ours (your current branch) and theirs (the branch being merged in).

Changed on one side only: Git takes that side's change.
Changed on both sides, in different places: Git keeps both changes.
Changed on both sides, in the same lines, differently: that is a conflict.

One line, two decisions

                merge base
            timeout = 30 minutes
             /              \
            /                \
     main (ours)        feature/login (theirs)
 timeout = 15 minutes   timeout = 60 minutes
            \                /
             \              /
               git merge  →  15?  60?  something else?

Both branches changed the same line. Either answer could be right, so Git refuses to guess.

Merges cleanly vs conflicts

Merges cleanly

Only one branch changed the file
Both changed the file, but in different parts
Both made exactly the same change

Conflicts

Both changed the same lines in different ways
Both changed lines right next to each other
One branch deleted a file the other changed

What a conflict looks like in the terminal

$ git merge feature/login

Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts
Automatic merge failed; fix conflicts and then commit the result.

The merge stops halfway. Files that merged cleanly are already staged; the conflicted file is written with conflict markers so you can see both versions. No merge commit exists yet. It is made when you finish.

Until then you can always back out with git merge --abort.