What does git merge do?
git merge <branch> takes the commits from another branch and brings them into the branch you are on. Only your current branch moves. The other branch stays where it was until you delete it.
The direction is the part people get backwards. To get opening-hours into main, you stand on main and merge opening-hours. Read the command as "merge that branch into here".
Check git status first. It tells you which branch you are on, and a merge needs a clean working folder: if you have uncommitted edits to files the merge would change, Git refuses to merge instead of mixing them up.
git status
git log --oneline --all
git merge opening-hoursWhat is a fast-forward?
If main has no new commits since the branch was made, the branch is just main plus some extra commits in a straight line. Git does not need to combine anything. It slides the main label forward to the branch's latest commit. That is a fast-forward, and the terminal prints Fast-forward.
No new commit is created. In the Graph, the main label jumps up the line and the history stays straight. Afterwards nobody can tell from the shape that a branch was ever used, which many people like for small changes.
In the bike shop repository, main gained "Add puncture price" after opening-hours was created, so this merge cannot fast-forward.
When does Git make a merge commit?
When both branches have commits the other lacks, Git finds the merge base: the last commit they share. It compares each side against that base and combines the two sets of changes. opening-hours changed hours.html; main changed index.html. Neither touches the other's file, so the result contains both.
Git records the result as a merge commit with two parents. Its default message is Merge branch 'opening-hours'. Real Git opens an editor so you can change that message; the practice terminal uses the default straight away. With real Git, git merge --no-edit opening-hours skips the editor.
In the Graph, two lines meet at the new dot. git log --oneline now lists commits from both branches, because both are part of main's history.
main label and adds no commit. When both sides have new work, Git makes a merge commit whose two parents join the lines back together.Why would you force a merge commit with --no-ff?
git merge --no-ff <branch> makes a merge commit even when a fast-forward was possible. The history then shows clearly that a group of commits arrived together, from a branch, at one moment. Some teams prefer this so they can see each feature as a unit, and revert it later with a single command.
Others prefer the straight line of fast-forwards. Both are reasonable; pick one per project. Pull requests on GitHub make a merge commit by default, which is the same as --no-ff.
git switch -c fix-typo
echo "<p>Open late Thursdays.</p>" >> index.html
git commit -am "Add late opening"
git switch main
git merge --no-ff fix-typo
git log --onelineWhat happens to the branch after merging?
Its label stays where it was, pointing at its last commit, which is now also part of main. Nothing breaks if you leave it. Over time, though, git branch fills with names of finished work, and it gets hard to tell which ones still matter.
Delete merged branches with git branch -d opening-hours. Lowercase -d checks that the branch's commits are in your current branch first, so it is safe to use as a habit. The commits stay; only the label goes.
If -d refuses with "not fully merged", stop and look. Either you merged into a different branch than you thought, or the branch has commits made after the merge.
git merge opening-hours
git branch -d opening-hours
git branchWhat if the same lines changed on both branches?
Git combines changes to different files, and to different parts of the same file, without asking. If both branches changed the same lines, Git cannot know which version you want. It stops with CONFLICT, writes both versions into the file between <<<<<<< and >>>>>>> markers, and waits for you.
The next lesson is all about resolving those. For now, the escape hatch is enough: git merge --abort puts everything back to how it was before the merge started.
The practice terminal compares files line by line, which is cruder than real Git's approach. Real Git can sometimes combine edits on nearby lines that the simulator treats as a conflict.
How do you check a merge did what you wanted?
Before pushing a merge to a published site, open the page. A merge with no conflicts can still produce a broken page if both branches made changes that make sense alone and clash together, such as two different headers.
git log --onelineshows the merge commit on top and commits from both branches below.git show HEADon a merge commit lists both parents on itsMerge:line.catthe files the branch changed and confirm the new content is there.git statusshould say the working tree is clean, with no merge in progress.- The Graph shows two lines joining at the top dot.
Why does the merge base matter?
Git compares each branch against the commit they last shared, never against each other directly. That is how it knows opening-hours added a Sunday line instead of main deleting one. Without the base, a line present on one side and absent on the other would be ambiguous.
It also explains why long-lived branches get harder to merge. The further both sides move from the base, the more likely they touch the same lines. Merging finished work back into main often, in small pieces, keeps conflicts rare.
What should you watch for in AI-suggested merge commands?
Check which branch you are on before running the suggestion. "Run git merge main" merges main into your current branch; if you are on main already, it does nothing, and if you are on a feature branch, it brings main's changes into the feature, which may be the opposite of what you wanted.
Watch for git pull used as a merge. git pull fetches from GitHub and merges in one step, so it can create merge commits you did not expect. The push and pull lesson covers that.
Be careful with git merge -X theirs or -X ours. They resolve conflicts automatically by picking one side, which can throw away changes without any warning.
Field notes
git merge <branch>brings another branch's commits into the one you are on.- If
mainhas no new commits, Git fast-forwards and just moves the label. - When both sides have new commits, Git makes a merge commit joining them.
- After merging, delete the old branch label with
git branch -d.
Easy to get wrong
A merge changes the branch you are on. To update main, you have to be on main.
Git refuses to merge over uncommitted changes to the files it needs to update, so the merge does not even start.
Capital -D deletes unmerged work without asking. Lowercase -d would have warned you.
Questions people ask
Does merging delete the other branch?
No. The branch stays until you delete it with git branch -d.
Can I undo a merge?
If it is not pushed, git reset --hard HEAD~1 right after a merge commit moves main back to before it. If it is pushed, revert it; real Git needs git revert -m 1 <id> for that.
What is the difference between merge and rebase?
Rebase replays your commits on top of the other branch instead of joining them with a merge commit, giving a straight line. It rewrites commits, so it has the same sharing risks as amend. The practice terminal has no rebase.
Why did my merge say Already up to date?
Everything on that branch is already in your current branch. Check you named the right branch, and that you committed your work on it.