Topic 25

Merging a Branch Back

Branching

The sightings page works. It should now be part of Sandpiper proper, which means the commits on sightings-page need to become part of main.

That is a merge: bringing one branch's commits into another. There is one rule to get right, and it is about where you are standing when you type the command.

The rule of position

Switch to the branch that should receive the work, then merge the other one into it.

Bring the sightings page into main

git switch main
git merge sightings-page

You stand on main, and you merge sightings-page into it. Getting this backwards — standing on the branch and merging main into it — is the most common beginner error here. It is not destructive and nothing breaks; you simply end up wondering why your work is not in main, because it is not.

The habit that prevents it: run git status and read the first line before typing merge.

The easy case: fast-forward

If main has not moved since you branched, Git has nothing to combine. All it has to do is slide the label forward:

Git saying there was nothing to combine

Updating c8d1e07..6e0a95c
Fast-forward
 index.html    | 3 +
 sightings.js  | 24 ++++++++++++++++++
 2 files changed, 27 insertions(+)

Fast-forward means exactly that: your branch's commits were built directly on top of main, so main can simply be moved to point at the newest one. No new commit is created because none is needed.

The real case: a merge commit

Now suppose main also gained a commit while you were working — you fixed the meeting time there. Both branches have moved, and Git has to combine two lines of work:

Git combining two lines of work

Merge made by the 'ort' strategy.
 sightings.js | 24 ++++++++++++++++++
 1 file changed, 24 insertions(+)

Git creates a merge commit: a commit with two parents, recording that two lines of work joined here. It is the one kind of commit that breaks the one-parent rule from Chapter 3, and it is why that rule was phrased carefully.

Git usually writes the message itself and does not ask you to. If it does open an editor with a proposed message, accept it — the escape from Chapter 2 works here too.

The two outcomes of a merge

Fast-forward

main had not moved — the label slides forward, no merge commit is created

Merge commit

both branches moved — a new commit with two parents records the join

Confirming

Both lines of work, now in one history

git log --oneline

The commits from the branch are in main's history. Open index.html and the sightings link is there. The work has landed, and main is once again the real version of the project.

The branch still exists

Merging does not delete the branch. The label is still there, still pointing at its last commit, and git branch still lists it.

That is deliberate: merge first, tidy afterwards. Cleaning up is the last topic of this chapter, and it is a separate decision from whether the work has landed.

Common Confusions

"I merge from the branch I am on." You merge into the branch you are on. Check the first line of git status before typing, every time.
"Fast-forward means Git skipped something." It means no combining was necessary, so no merge commit was needed. It is the cleanest possible outcome.
"A merge commit is clutter that should be avoided." It is the record that two lines of work joined. Removing them is what rebase is for, which is an argument this book deliberately does not have.
"Merging deletes the branch I merged." The label is untouched and still lists in git branch. Deleting it is a separate command and a separate decision.

Why It Matters

Merging is how every piece of work reaches main, whether you type the command yourself or GitHub does it for you when a pull request is merged in Chapter 8.
The direction rule prevents the confusing state where a beginner merges main into their feature branch, sees no errors, and cannot find their work in main.
Knowing that a merge commit has two parents is what makes the history readable later: it is the visible seam where two efforts met.

Knowledge Check

You want the work from sightings-page to end up in main. What do you do?

Switch to main first, then run git merge sightings-page there
Stay on sightings-page and run git merge main to combine them
Run git merge with both branch names, in the order they should combine
Delete main and rename sightings-page to take its place

Git reports "Fast-forward" after your merge. What does that mean?

main had not moved, so the label simply slid forward to your commit
Git skipped some commits to save time and will apply them in the background
The merge was incomplete and needs a second command to finish properly
Your branch's commits were combined into a single commit before merging

What is unusual about a merge commit compared with an ordinary one?

It has two parents, which records that two lines of work joined there
It contains no file changes of its own, only a reference to the two branches
It cannot be reverted later, because undoing it would split the history again
It is created automatically without a message, unlike commits you make yourself

After a successful merge, what has happened to the branch you merged?

Nothing, since the label still exists and still points at its last commit
It was deleted automatically, since its commits now live in main
It was renamed to show that it has been merged and is no longer active
It was archived, so it no longer appears in the output of git branch

You got correct