DailyRNG
Login
Basic

The merge that refused to cooperate

The first conflict I ever saw had red markers bleeding across my file and I nearly deleted the whole thing. They are just markers, and the fix is slower but calmer than you'd think.

What you will see

[main def5678] Merge branch 'feature' 1 file changed, 1 insertion(+), 1 deletion(-)

About 2 min of reading

Try It

The first conflict I ever saw had red markers bleeding across my file and I nearly deleted the whole thing. Let me build the situation myself: two branches editing the same line, then the merge that refused to pick.

1

Start a file with one line everyone will edit, and make a clean commit. Now the file has exactly one version to argue about, and both branches will start from this same point.

echo "server runs" > notes.txt git add notes.txt git commit -m "Add notes"

Before you run it, say out loud what it will print. Then open the answer.

What it prints
[main abc1234] Add notes 1 file changed, 1 insertion(+)
The line above is the shared starting point. Each branch will change it differently, which is what forces the conflict.
2

Create a new branch and change that same line to a different value. On my branch the note says one thing; a teammate on main might have changed it to something else. Now the two branches disagree on that one line.

git checkout -b feature echo "server is down" > notes.txt

Before you run it, say out loud what it will print. Then open the answer.

What it prints
Switched to a new branch "feature"
This does not touch main yet, it only changes my working copy on the feature branch. That is how the two branches drift apart.
3

Go back to main, change the very same line to something else, then merge feature in. Both sides edited the same line, so git cannot guess which one is right. It stops and leaves markers in the file.

git checkout main echo "server is fine" > notes.txt git merge feature

Before you run it, say out loud what it will print. Then open the answer.

What it prints
Auto-merging notes.txt Conflict: merge conflict in notes.txt Merge made by the 'ort' strategy. notes.txt: needs merge
The merge did not finish. Git left the markers in the file and will not commit until I resolve them and stage the file again.
4

Read the markers, not panic at them. <<<<<<< HEAD is my side (main), >>>>>>> feature is theirs, and ======= splits them. Everything between is the argument. My job is to pick one, or blend them, then throw the markers away.

type notes.txt

Before you run it, say out loud what it will print. Then open the answer.

What it prints
<<<<<<< HEAD server is fine ======= server is down >>>>>>> feature
If I commit with these markers still in the file, git refuses. Every marker line has to be gone before the merge closes.
5

Edit the file down to the final version I want and delete every marker. Then stage it and commit to finish the merge. Git treats that commit as the final decision, and the conflict disappears from history.

echo "server is fine, restarting" > notes.txt git add notes.txt git commit

Before you run it, say out loud what it will print. Then open the answer.

What it prints
[main def5678] Merge branch 'feature' 1 file changed, 1 insertion(+), 1 deletion(-)
The commit message git offers automatically describes a merge. It is fine to accept it, or edit it to say why I chose one version over the other.

Put it in order

Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.

Data Flow

Two branches edit the same lines, git stops, you choose the winner, and the merge commits.
1 Git detects overlapping edits
↓
2 It writes conflict markers
↓
3 You edit the file to resolve
↓
4 Stage the resolved file
↓
5 Commit to finish the merge
Why this works
Why conflicts happen

Conflicts are the rule when two people edit the same place, not the exception:

  • Both branches rewrote the same lines.
  • One branch deleted a file the other changed.
  • The automatic merge simply cannot decide.

Git would rather stop and ask than guess wrong and corrupt your work. A conflict is a small conversation between you and the code, and you almost always know the answer.

The fix, step by step

Never commit with the markers still in the file, git will refuse. Close the loop like this:

git add .          # stage the resolved file
git commit         # finish the merge

Stage the file once it is clean. Git treats that commit as the final decision, and the conflict disappears from history.

Examples

When a merge fights back

git merge feature
# CONFLICT in notes.txt

A conflict shows up when two branches changed the same lines differently. Git cannot guess which version is right, so it stops and leaves markers in your file. This is not a crash, it is git handing the decision to you.

Reading the markers

<<<<<<< HEAD
my version of the line
=======
their version of the line
>>>>>>> feature

<<<<<<< HEAD is your side, >>>>>>> is theirs, and ======= splits them. Everything between is the argument. Your job is simple: pick one, or blend them, then throw the markers away.

Make the call and commit

git add notes.txt
git commit

Edit the file down to the final version you want, delete the markers, stage it, and commit to finish the merge. Git keeps the merge in progress until you do this, so if you forget, the project will nudge you every time you try to commit.

Words this lesson uses

Each one is defined here on this site. Open the entry for the full definition and the other words it points at.

← Letting other people in
Previous Lesson
Letting other people in
Next Lesson
Pigeonholing uncommitted work
Pigeonholing uncommitted work →