Week 2: Branching & Merging

1. Why Branch?

A branch is just a movable pointer to a commit — creating one is instant and cheap because it doesn't copy any files. main (or historically master) is the conventional default branch; everything else is a parallel line of history that starts from wherever you branched off.

The usual reason to branch: isolate work in progress from the stable, deployable state of main. You build a feature or fix a bug on its own branch, and only bring it into main once it's done and reviewed — that way main stays something you can deploy from at any moment.

2. Creating & Switching Branches

git branch                       # list local branches, * marks the current one
git branch feature/login         # create a new branch (doesn't switch to it)
git switch feature/login         # switch to it
git switch -c feature/signup     # create AND switch in one step

git branch -d feature/login      # delete a branch (only if merged)
git branch -D feature/login      # force-delete, even if unmerged

git switch is the modern, purpose-built command for changing branches (Git 2.23+). You'll also see git checkout <branch> in older tutorials and codebases — it does the same job, but checkout is an older, overloaded command that also does several unrelated things (like restoring files), which is exactly why switch was split out.

git switch -c feature/signup
echo "signup form" > signup.html
git add signup.html
git commit -m "Add signup page skeleton"

git switch main
cat signup.html
# cat: signup.html: No such file or directory

That last line is the point: main genuinely doesn't have signup.html yet. Each branch has its own independent working directory state, computed from its own commit history.

3. Fast-Forward vs. Three-Way Merges

git merge <branch>, run from the branch you want to merge into, combines another branch's history into the current one. There are two outcomes:

Fast-forward merge — if main hasn't moved since you branched off it, Git just slides the main pointer forward to your branch's latest commit. No new commit is created:

git switch main
git merge feature/signup
# Updating 3f9a1c2..7b2e910
# Fast-forward
#  signup.html | 1 +

Three-way merge — if main has moved (someone else merged something), Git looks at three commits — the two branch tips plus their common ancestor — and creates a new merge commit with two parents, combining both histories:

git switch main
git merge feature/login
# Merge made by the 'ort' strategy.
#  login.html | 1 +
# (a new merge commit is created, with two parent commits)

Both are equally valid — a fast-forward simply means there was nothing to reconcile. If you always want an explicit merge commit for traceability even when a fast-forward is possible, use git merge --no-ff.

4. Resolving Merge Conflicts

A conflict happens when both branches changed the same lines of the same file. Git can't guess which version you want, so it pauses the merge and marks the file for you to resolve by hand:

git merge feature/pricing
# Auto-merging pricing.html
# CONFLICT (content): Merge conflict in pricing.html
# Automatic merge failed; fix conflicts and then commit the result.

<h1>Pricing</h1>
<<<<<<< HEAD
<p>Starting at $9/month</p>
=======
<p>Starting at $12/month, billed annually</p>
>>>>>>> feature/pricing

<<<<<<< HEAD down to ======= is your current branch's version; ======= down to >>>>>>> feature/pricing is the incoming branch's version. Edit the file down to what it should say — deleting the marker lines entirely — then stage and commit:

# after manually editing pricing.html to the final text:
git add pricing.html
git commit -m "Merge feature/pricing, resolve pricing copy conflict"

5. Rebase Basics: Rebase vs. Merge

git rebase main, run from a feature branch, replays that branch's commits one by one on top of main's latest state — instead of creating a merge commit, it rewrites the feature branch's history so it looks like it was built starting from where main is now:

git switch feature/signup
git rebase main
# Successfully rebased and updated refs/heads/feature/signup.

The result: a clean, linear history with no merge commits — often preferred for feature branches before they're merged, because it reads like the work happened in a straight line. The trade-off is that rebase rewrites commit hashes, so it's only safe on branches nobody else has already pulled and built on top of. Merge is always safe on shared branches; rebase is a local cleanup tool. Week 4 covers rewriting history in more depth.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.