You’ve got a finished footer branch and a main branch that doesn’t have it yet. Merging is how work on one line of history joins another. Git has two ways to do it, and which one happens isn’t random: you can predict it by looking at the graph before you type anything.
First, the rule that saves the most confusion: you merge another branch into the branch you’re on. git merge footer means “bring footer’s work into my current branch.” Only the current branch moves. The branch you named is left exactly where it was.
So the routine is always: switch to the branch that should receive the work, then merge.
\ngit switch main\ngit merge footerSince you made footer, nobody committed on main. Every commit on main is already in footer’s history. Git doesn’t need to combine anything; it slides main forward to footer’s latest commit:
Updating c39be11..f1a3b07\nFast-forward\n index.html | 8 ++++++++\n styles.css | 12 ++++++++++++\n 2 files changed, 20 insertions(+)That’s a fast-forward: no new commit, just a pointer moving along existing commits. History stays a straight line, as if you’d worked on main all along.
Now the more interesting case. While you built dark-mode, you also fixed a typo directly on main. Both branches have commits the other lacks; they’ve diverged. There’s no straight line to slide along.
Git does a three-way merge. It finds the merge base, the most recent commit both branches share, and compares each branch tip with it. A change made on only one side is taken. Changes on both sides in different places are both taken. If both sides changed the same lines, Git stops and asks you; that’s a conflict, and it gets the whole next lesson.
\ngit switch main\ngit merge dark-modeGit opens your editor with the message Merge branch 'dark-mode'. Save and close, and you’ll see:
Merge made by the 'ort' strategy.\n styles.css | 24 ++++++++++++++++++++++++\n 1 file changed, 24 insertions(+)ort is the name of Git’s default merge algorithm; you don’t need to choose it. The result is a merge commit: a commit with two parents, the previous main tip and the dark-mode tip. Its snapshot contains both lines of work.
Both results contain the same final files. What differs is how history reads, and teams have opinions.
\nTwo flags let you pick instead of letting the graph decide:
\ngit merge --no-ff footer # always create a merge commit, even if fast-forward is possible\ngit merge --ff-only footer # fast-forward or refuse; never create a merge commitMy default for a solo portfolio: let Git fast-forward small branches, and don’t agonise over it. On a team, follow the team’s convention, which is usually set on GitHub rather than typed by hand. What matters far more than the policy is that each branch carries one coherent piece of work, so whichever shape history takes, every step in it makes sense.
\n--ff-only is a good safety habit when you only expect to catch up, for example updating your local main. If Git refuses, that’s news: something diverged that you didn’t know about. On GitHub you’ll meet the same choice as merge methods on a pull request in section 3.
You can check the merge base yourself before merging, which tells you how far the branches have drifted:
\ngit merge-base main dark-mode\ngit log --oneline main..dark-mode # commits on dark-mode that main lacks\ngit log --oneline dark-mode..main # and the reverseIf the second log is empty, main hasn’t moved and the merge will fast-forward.
Once footer is merged, the branch label has done its job. Delete it:
git branch -d footer-d succeeds because the commits are reachable from main. The commits themselves stay in history forever; only the sticky note goes. Clean up merged branches as you go, and git branch stays a short list of work that’s actually in progress.
So far every merge went smoothly because the two branches touched different lines. Next you’ll make them collide on purpose and resolve the conflict step by step.
\n","toc":[{"id":"sec-1","text":"The rule of direction","level":2},{"id":"sec-2","text":"Case 1: fast-forward","level":2},{"id":"sec-3","text":"Case 2: a true merge","level":2},{"id":"sec-4","text":"Choosing on purpose","level":2},{"id":"sec-5","text":"After the merge","level":2}],"takeaways":["You always merge another branch into the branch you’re on; only the current branch moves.","If the current branch hasn’t moved since the other branch started, Git fast-forwards the pointer and creates no new commit.","If both branches have new commits, Git does a three-way merge from their common ancestor and records a merge commit with two parents.","--no-ff forces a merge commit to keep a feature grouped; --ff-only refuses anything but a fast-forward."],"further":[{"title":"Basic Branching and Merging (Pro Git)","url":"https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging"},{"title":"git merge reference","url":"https://git-scm.com/docs/git-merge"},{"title":"git merge-base reference","url":"https://git-scm.com/docs/git-merge-base"}],"quiz":[{"q":"You’re on main. Since you created footer from it, main has gained no commits and footer has three. What does git merge footer do?
main forward to footer’s latest commit without creating a new commit.","why":"Correct. main is an ancestor of footer, so Git can fast-forward the pointer. History stays a straight line."},{"text":"Creates a merge commit with two parents.","why":"That happens only when both branches have moved, or when you ask for it with --no-ff."},{"text":"Copies the three commits onto main with new IDs.","why":"That describes rebasing or cherry-picking. A merge reuses the existing commits."},{"text":"Moves footer back to where main is.","why":"A merge never moves the branch you name, only the branch you’re on."}],"answer":0},{"q":"You meant to bring dark-mode into main, but you were on dark-mode and ran git merge main. What happened?
main into a feature branch.","why":"You can, and teams do it to bring a long-running branch up to date. It’s legal, just not what you wanted here."},{"text":"main now contains the dark mode work.","why":"main didn’t move. Only the branch you’re on, dark-mode, can change during a merge."},{"text":"dark-mode gained main’s new commits; main is unchanged.","why":"Correct. Switch to main with git switch main and run git merge dark-mode to merge in the direction you intended."}],"answer":3},{"q":"Which commit does Git use as the starting point when it does a three-way merge of dark-mode into main?
Your team wants every feature to appear in main’s history as one merge commit, even when a fast-forward would be possible. Which option gives that?
git merge --ff-only feature","why":"That’s the opposite policy. It allows only fast-forwards and refuses to create merge commits."},{"text":"git merge --squash feature","why":"That stages the combined changes without committing or recording a second parent, so the branch link is lost."},{"text":"git merge --no-ff feature","why":"Correct. It always records a merge commit, so the feature’s commits stay grouped on their own line in the graph."},{"text":"git merge --all feature","why":"git merge has no --all option."}],"answer":2}],"exercise":{"kind":"choice","multiple":false,"options":["a","b","c","d"],"correct":["b"],"title":"Predict the merge","prompt":"This is the portfolio right now. Arrows point from each commit to its parent.
\n:::figure Before the merge\n
\nThe two branches touched different files. You run git merge projects-grid. What does the graph look like afterwards?
main gained commits since projects-grid split off at b2?","When both sides have new commits, a fast-forward is impossible."],"explanation":"HEAD is on main, so main is the branch that moves. Both branches have commits since their merge base b2 (c3 on main; d4 and e5 on projects-grid), so a fast-forward is impossible. Git does a three-way merge from b2 and records a new merge commit whose parents are c3 and e5. main moves to it; projects-grid stays on e5 until you delete it.
main fast-forwards to e5; no new commit is made.","why":"A fast-forward needs main to be an ancestor of e5. c3 isn’t in projects-grid’s history, so Git can’t slide main along a straight line."},"b":{"text":"A new merge commit with parents c3 and e5 appears; main moves to it and projects-grid stays on e5.","why":"Correct. Both sides moved since b2, so Git creates a two-parent commit on the current branch only."},"c":{"text":"A new merge commit appears and both main and projects-grid move to it.","why":"Only the branch you’re on moves during a merge. projects-grid keeps pointing at e5."},"d":{"text":"d4 and e5 are copied after c3 with new IDs, keeping history linear.","why":"That’s what a rebase does. A merge keeps the original commits and joins the two lines with a merge commit."}}},"words":722,"readMinutes":3}