Merging: fast-forward vs true merge

Bringing branches together

Your new-sauce experiment worked and its commits deserve to be on main. That's a merge, and the direction matters: you stand on the branch that should receive the work, then pull the other branch in.

$ git switch main
$ git merge new-sauce

What Git does next depends on one question: did main move while you were away on the branch? The two possible answers give the two kinds of merge.

Reading both outcomes

Fast-forward. main gained no commits since you branched, so your branch's history is a simple continuation. Git slides the main label forward. No new commit is created:

$ git merge new-sauce
Updating a1b2c3d..c7d8e9f
Fast-forward
 sauce.txt | 3 +++

True merge. Both branches gained commits, the histories genuinely diverged. Git combines both sets of changes and seals them with a merge commit, the only kind of commit with two parents, one on each branch:

$ git merge new-sauce
Merge made by the 'ort' strategy.
 sauce.txt | 3 +++

Usually Git combines the branches automatically, changes to different files, or different lines, merge cleanly. When both branches edited the same lines, Git stops and asks you to decide. That's a merge conflict, and it gets all of unit 6.

After the merge: delete the label

Once new-sauce is merged, its commits live on main. Keeping the branch around buys nothing — real repositories otherwise silt up with dozens of dead branches — so the routine is merge, then delete:

$ git branch -d new-sauce
Deleted branch new-sauce (was c7d8e9f).

Deleting a branch deletes only the label file from lesson 5-1, never the commits: they are reachable from main now, and git log still shows them. Safety is built in, too — -d refuses to delete a branch whose commits are not merged anywhere (you'd be orphaning work), and the capital -D variant is the explicit "yes, discard that experiment" override.