Branching and Merging

By the end of this lesson you'll be able to spin up an isolated branch to build a feature, switch between lines of work, merge them back, and clean up — the core skill that turns Git from "save button" into real team collaboration.

Learn Branching and Merging in our free Git course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick reference.

Part of the free Git course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

1️⃣ Why Branches Exist

A branch is just a movable label that points at a commit. That's it — Git copies no files when you branch, it simply writes one new pointer, so creating a branch is instant even in a huge project. The point of a branch is isolation : you can build a half-finished feature, break things, and experiment freely without ever putting the shared main branch at risk. When the work is good you merge it back; if it's a dead end you throw the branch away and lose nothing else.

Your turn. Start a new feature on its own branch, prove you're on it, and make a commit. Fill in the three blanks marked ___ using the hints in the comments.

2️⃣ HEAD — "You Are Here"

HEAD is Git's "you are here" marker. Nearly always it points at the branch you're currently on, and that branch points at your latest commit — so HEAD → main → a1b2c3d . When you switch branches, HEAD simply moves to point at the other branch. It's a label tracking your position, not a separate copy of your code.

3️⃣ Merging Branches

Merging brings the commits from one branch into another. First switch to the branch you want to receive the work, then run git merge with the branch you want to pull in. Git picks one of two strategies automatically. A fast-forward happens when main hasn't moved since the branch split off — Git just slides the main label forward and history stays perfectly linear. A three-way merge happens when both branches gained commits — Git can't slide the label, so it builds a new merge commit with two parents to tie the lines of history together.

4️⃣ Deleting Merged Branches

Once a branch is merged, its commits live safely on the branch you merged into, so the branch label has done its job. Delete it with git branch -d name — the lower-case -d is the safe delete: Git refuses if the branch isn't fully merged, protecting you from losing commits. The capital -D is the force delete — it throws the branch away even if its work was never merged, so reach for it only when you genuinely want to discard that experiment.

Now put the whole loop together: switch to main , merge your finished feature, and safely delete it. Fill in the three blanks.

5️⃣ Visualising Your History

Reading branches as plain text gets confusing fast. One command draws your entire repository as an ASCII graph — every branch, every merge, every commit — right in the terminal. Learn this early; it's the fastest way to build a mental picture of what your branches are doing.

6️⃣ Rebase vs Merge

git rebase replays your commits on top of another branch for a clean, linear history instead of a merge commit. It's powerful but dangerous on shared branches. Follow the golden rule: never rebase commits you've already pushed , because rebasing rewrites history and breaks anyone who already pulled it.

7️⃣ git stash — Quick Save

git stash temporarily shelves your uncommitted changes so you can switch branches with a clean working directory. When you come back, git stash pop restores everything exactly as it was — perfect for when an urgent bug interrupts your half-finished feature.

📋 Quick Reference

No commands given this time — just the plan and a blank canvas. Work through the whole branch lifecycle in your own terminal, then check your graph against the expected result in the comments.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary