Merging and Conflicts

Merging

When work on a branch is done, you merge it into another branch, usually main. Switch to the branch that should receive the work, then name the branch to bring in ¹:

me@linuxbox:~/garden$ git switch main
me@linuxbox:~/garden$ git merge fence

What git does next depends on whether both branches have moved.

Fast-forward

If main hasn’t changed since notes split off from it, main is simply behind. Git doesn’t need to combine anything; it moves main forward to where notes is. That’s a fast-forward ¹:

me@linuxbox:~/garden$ git merge notes
Updating d2de332..2776660
Fast-forward
 notes.txt | 1 +
 1 file changed, 1 insertion(+)

No new commit is made.

Three-way merge

If both branches have new commits, git combines them. It finds their common ancestor, the last commit they share, and compares each branch’s tip with it: changes made on only one side are kept, changes on both sides are combined. The result is a new merge commit with two parents ¹:

me@linuxbox:~/garden$ git merge --no-edit fence
Merge made by the 'ort' strategy.
 fence.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 fence.txt
me@linuxbox:~/garden$ git log --oneline --graph
*   d2de332 Merge branch 'fence'
|\
| * d595886 Plan the fence
* | e86b128 Add lettuce
|/
* 043dfca Plan the beds

Without --no-edit, git opens your editor with the message “Merge branch ‘fence’” for you to accept or expand. (‘ort’ is the name of git’s current merge algorithm.)

Most merges are like this: changes in different files, or different parts of the same file, combine on their own.

Conflicts

If both branches changed the same lines differently, git can’t know which you want. It stops with a conflict ¹:

me@linuxbox:~/garden$ git merge spacing
Auto-merging fence.txt
CONFLICT (content): Merge conflict in fence.txt
Automatic merge failed; fix conflicts and then commit the result.
me@linuxbox:~/garden$ git status
On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
    both modified:   fence.txt

Git has written both versions into the file, between conflict markers ¹:

<<<<<<< HEAD
cedar posts, 10 ft apart
=======
cedar posts, 6 ft apart
>>>>>>> spacing

• Between <<<<<<< HEAD and =======: your version, from the branch you’re on.
• Between ======= and >>>>>>> spacing: the other branch’s version.

To resolve it ¹:

1. Edit the file to say what it should: one version, the other, or a mix. Delete all three marker lines.
2. git add fence.txt to mark it resolved.
3. git commit to finish the merge (the message is filled in for you).

me@linuxbox:~/garden$ nano fence.txt                 # leave: cedar posts, 8 ft apart
me@linuxbox:~/garden$ git add fence.txt
me@linuxbox:~/garden$ git commit --no-edit

Changed your mind partway through? git merge --abort puts everything back as it was before the merge ¹.

Editors like VS Code show conflicts with buttons for “accept current,” “accept incoming,” or both, which does the same edit for you. However you resolve it, search the file for <<<<<<< before committing: a leftover marker is an easy mistake to commit.

Keeping conflicts small

• Merge often, so branches don’t drift far apart.
• Keep branches focused on one thing.
• Pull in main’s changes partway through a long branch (git merge main while on the branch), so conflicts come in small pieces.

Your turn

So

Switch to the receiving branch and git merge the other. If yours hasn’t moved, it’s a fast-forward; if both have, git makes a merge commit with two parents from their common ancestor. Conflicts show both versions between <<<<<<<, =======, and >>>>>>>: edit to what it should be, git add, git commit, or git merge --abort.