Git Branches and Merging: Fast-Forward, Merge Commits and Conflicts

Two merges, same command, different results: one leaves no trace in the history, the other adds a commit with two parents, and a third stops halfway and asks you a question. Which one you get depends on whether both sides of the merge have moved. This lesson uses a trail-guide repository with three branches to produce each case on purpose, so you recognise them when they happen by surprise.

A branch is a movable label

A branch is a name that points at one commit. When you commit, the label moves forward to the new commit. HEAD records which branch you are on, and git switch <branch> moves HEAD and rewrites your working folder to match that branch's latest snapshot. Creating a branch copies nothing; it writes a short pointer, so branching is cheap enough to do for every small change. git switch -c <name> creates and switches in one step. (Older tutorials use git checkout for both jobs; switch and restore split that command into clearer pieces.)

Fast-forward: main did not move

The repository starts with one commit listing three routes. We branch off, add a fourth route, go back to main and merge. Since main has no new commits of its own, Git has nothing to combine. It just slides the main label forward. Lines starting with # in the transcript are edits made in a text editor.

$ git switch -c add-night-route
Switched to a new branch 'add-night-route'

# edit routes.txt: add the line "Night walk, 3 km"

$ git commit -am "Add the night walk"
[add-night-route 5d04e08] Add the night walk
 1 file changed, 1 insertion(+)

$ git switch main
Switched to branch 'main'

$ git merge add-night-route
Updating 27e8197..5d04e08
Fast-forward
 routes.txt | 1 +
 1 file changed, 1 insertion(+)

$ git branch -d add-night-route
Deleted branch add-night-route (was 5d04e08).

$ git log --oneline --graph
* 5d04e08 Add the night walk
* 27e8197 List the three starter routes

Fast-forward in the output is the whole story. The graph is a straight line, and afterwards nobody can tell a branch ever existed. Deleting the merged branch with -d is safe; Git refuses -d on a branch with unmerged work and prints error: the branch '...' is not fully merged, which is the cue to merge it or consciously use -D.

A merge commit: both sides moved

Now two people work in parallel. One branch corrects a distance in routes.txt; meanwhile main gains a new file, safety.txt. The histories have diverged, so sliding a label is impossible. Git builds a new commit whose content combines both and which has two parents.

$ git switch -c fix-lake-distance
Switched to a new branch 'fix-lake-distance'

# edit routes.txt: change "Lake path, 4 km" to "Lake path, 4.5 km"

$ git commit -am "Correct the lake path distance"
[fix-lake-distance 3276570] Correct the lake path distance
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git switch main
Switched to branch 'main'

$ echo 'Bring water on the ridge loop.' > safety.txt

$ git add safety.txt

$ git commit -m "Add safety note"
[main 26065c6] Add safety note
 1 file changed, 1 insertion(+)
 create mode 100644 safety.txt

$ git merge fix-lake-distance -m "Merge fix-lake-distance"
Merge made by the 'ort' strategy.
 routes.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git log --oneline --graph
*   5d668a3 Merge fix-lake-distance
|\
| * 3276570 Correct the lake path distance
* | 26065c6 Add safety note
|/
* 5d04e08 Add the night walk
* 27e8197 List the three starter routes

The graph shows the diamond: two lines that left a common commit and joined at the merge commit. The strategy name ort is just Git's default algorithm. Git merged automatically because the two edits touched different files. Two variations are worth knowing. git merge --no-ff <branch> forces a merge commit even when a fast-forward is possible, keeping the branch visible in history. git merge --squash <branch> stages the combined changes without a merge commit, so you record them as one commit of your own.

A conflict: both sides touched the same line

Last scenario. One branch marks the ridge loop as steep; main re-measures the same line as 8.4 km. Git cannot choose between two edits of one line, so it stops, marks the file and waits.

$ git switch -c rename-ridge
Switched to a new branch 'rename-ridge'

# edit routes.txt: change "Ridge loop, 8 km" to "Ridge loop (steep), 8 km"

$ git commit -am "Flag the ridge loop as steep"
[rename-ridge e9e1b5f] Flag the ridge loop as steep
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git switch main
Switched to branch 'main'

# edit routes.txt: change "Ridge loop, 8 km" to "Ridge loop, 8.4 km"

$ git commit -am "Re-measure the ridge loop"
[main 7a3a653] Re-measure the ridge loop
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git merge rename-ridge
Auto-merging routes.txt
CONFLICT (content): Merge conflict in routes.txt
Automatic merge failed; fix conflicts and then commit the result.

$ git status -s
UU routes.txt

$ cat routes.txt
Lake path, 4.5 km
<<<<<<< HEAD
Ridge loop, 8.4 km
=======
Ridge loop (steep), 8 km
>>>>>>> rename-ridge
Quarry steps, 2 km
Night walk, 3 km

$ git merge --abort

$ git status
On branch main
nothing to commit, working tree clean

$ git merge rename-ridge
Auto-merging routes.txt
CONFLICT (content): Merge conflict in routes.txt
Automatic merge failed; fix conflicts and then commit the result.

# edit routes.txt: resolve it: delete the markers and keep one combined Ridge line

$ cat routes.txt
Lake path, 4.5 km
Ridge loop (steep), 8.4 km
Quarry steps, 2 km
Night walk, 3 km

$ git add routes.txt

$ git commit --no-edit
[main 31912ac] Merge branch 'rename-ridge'

$ git log --oneline --graph
*   31912ac Merge branch 'rename-ridge'
|\
| * e9e1b5f Flag the ridge loop as steep
* | 7a3a653 Re-measure the ridge loop
|/
*   5d668a3 Merge fix-lake-distance
|\
| * 3276570 Correct the lake path distance
* | 26065c6 Add safety note
|/
* 5d04e08 Add the night walk
* 27e8197 List the three starter routes

$ git branch --merged
  fix-lake-distance
* main
  rename-ridge

$ git branch -d rename-ridge fix-lake-distance
Deleted branch rename-ridge (was e9e1b5f).
Deleted branch fix-lake-distance (was 3276570).

Everything between <<<<<<< HEAD and ======= is your side, the branch you are on. Everything between ======= and >>>>>>> rename-ridge is the incoming side. Status UU means both modified. Notice the safe exit in the middle: git merge --abort put everything back exactly as before, so you can retreat at any point. To resolve:

1. Open the conflicted file and decide the final text for each marked region.
2. Delete all three marker lines (<<<<<<<, =======, >>>>>>>). Git does not remove them for you.
3. Run git add <file> to tell Git that conflict is resolved.
4. Run git commit (here --no-edit accepts the prepared message) to finish the merge.

Common mistakes

• Committing the conflict markers. Symptom: the build fails with a syntax error pointing at <<<<<<< HEAD, or the site shows the markers as text. Search the project for <<<<<<< before finishing a merge.
• Switching branches with uncommitted edits to the same file. Symptom: error: Your local changes to the following files would be overwritten by checkout followed by Aborting. Commit the work, or use git stash and git stash pop.
• Committing on the wrong branch. Symptom: your feature commit shows up in git log on main. Create a branch at that point with git switch -c feature and then fix main using the reset techniques in the last lesson.
• Long-lived branches. Symptom: the eventual merge produces dozens of conflicts in files you never touched. Merge main into your branch regularly, or keep branches to a day or two of work.

How this shows up in projects and interviews

Merge conflicts are a normal part of team work, and how you handle one says a lot: you read both sides, resolve deliberately, run the tests and say what you did in the commit. Common interview questions are fast-forward versus merge commit, merge versus rebase (a rebase replays your commits on top of the other branch, producing a straight history, and the next lesson shows it on a real push), and what HEAD is. Teams also differ on whether to keep merge commits; your job at first is to follow the team's rule. See Collaborating in a Team for the human side of sharing a codebase.