Practice: Branches as parallel work surfaces

Self-check questions

Answer each in your own words first, then open the answer to check.

Q1. In your own words, what is a branch in git? Specifically address what a branch is NOT.

Show answer

A branch in git is a movable pointer to a commit. It is a label on the snapshot graph that can be advanced as new commits land. It is NOT a copy of the code. It is NOT a folder. It is NOT a place where files live. Files live in commits (snapshots); branches just point to one snapshot at a time.

Q2. You are on main. You run git switch -c feature/login. You commit one change. Then you run git switch main. Where is main? Where is feature/login? Where is HEAD?

Show answer

After git switch -c feature/login from main, both main and feature/login point to the same commit. After committing one change, feature/login advances to the new commit; main stays put. After git switch main, HEAD now points to main (which is at the original commit); feature/login still points to its commit. Your working directory is repopulated to match main’s snapshot, so your feature work appears to “disappear” from the working files. It is still safe, sitting in the commit that feature/login points to.

Q3. Why are git branches considered “cheap,” and what does that cheapness enable that older version control systems could not easily do?

Show answer

Git branches are cheap because creating one is a single filesystem write (a small pointer file containing the SHA of the commit the branch points to). No code is copied. Switching is fast because the working directory just gets repopulated from the target snapshot. In SVN/CVS, a branch was a server-side copy of the entire codebase, expensive and slow. Git’s cheapness enables: branch-per-feature workflows, pull request reviews on every change, frictionless experimentation (failed experiments cost nothing to discard), and the whole modern collaboration model that GitHub / GitLab / Bitbucket built on top.

Q4. You run git branch -d feature/old-experiment and get an error: “branch is not fully merged.” Two questions: (a) what does this error mean? (b) what are your options for proceeding?

Show answer

(a) The error means the branch has commits that have NOT been merged into your current branch (or any branch that you have checked out / are in). Git is warning you: deleting the branch would orphan those commits from any named reference. They would still exist in the reflog for about 90 days, but no branch would point to them. (b) Three options: (1) Merge the branch first (git merge feature/old-experiment from main), then git branch -d succeeds because the work is now in main. (2) If you really want to abandon the work, use git branch -D feature/old-experiment (capital D forces). The commits live in reflog for 90 days. (3) If you are unsure, leave the branch alone and come back when you have decided whether the work is worth keeping.

Q5. When SHOULD you branch, and when should you commit directly to your current branch? Give one example of each.

Show answer

Branch when: (a) the work is separable and could ship as its own unit, (b) you are experimenting, (c) you need to context-switch mid-feature to fix a bug, (d) the work will be reviewed before landing in main. Commit directly when: (a) the change is trivial (typo fix on a solo project), (b) you are working solo with no collaborator and no production deployment, (c) you are doing a series of related commits that should land together as one unit.

Example of branch: you are working on a payment-flow feature. Halfway through, production breaks. Branch the bug fix onto hotfix/critical-issue so it can ship independently without your half-finished feature work.

Example of commit directly: you are on main of a personal project, you noticed a typo in a comment, you fix it and commit. No branch needed. Cost of branch exceeds value of branch for a one-line fix in a solo project.

Branch creation drill

Run these in a sandbox repository. The goal is muscle memory.

Drill 1, create, switch, observe:

Start on main. Verify with git branch (should show * main).
Make a commit on main so the repo has at least one commit.
Create and switch to a new branch: git switch -c experiment/first.
Run git branch and verify experiment/first now has the asterisk.
Run git log --oneline --all --decorate --graph and observe both branches point to the same commit.

Drill 2, diverge:

From experiment/first, make a commit (any small change).
Run git log --oneline --all --decorate --graph and observe experiment/first is now one commit ahead of main.
Switch back to main (git switch main).
Run git log --oneline --all --decorate --graph and observe main is at the original commit, experiment/first is one ahead.
Make a different commit on main.
Run git log --oneline --all --decorate --graph and observe the diverged history. The graph should show a fork.

Drill 3, HEAD tracking:

While on main, run cat .git/HEAD. Observe it says ref: refs/heads/main.
Switch to experiment/first. Run cat .git/HEAD again. Observe it now says ref: refs/heads/experiment/first.
This is HEAD literally. It is a file that contains the name of your current branch.
Try cat .git/refs/heads/main. Observe it contains a commit SHA. This is the literal pointer.

Drill 4, branch listing:

From main, create three branches without switching: git branch feature/one, git branch feature/two, git branch bugfix/sample.
Run git branch. All four branches listed; * main has the asterisk.
Run git branch | grep feature/. Confirm the filter works.

Drill 5, safe delete:

From main, try git branch -d experiment/first. Git refuses because the branch has unmerged work.
Read the error message carefully: it tells you exactly what to do (merge first or use -D).
Use git branch -D experiment/first to force-delete.
Run git reflog and confirm the commits are still recoverable (they live in reflog for about 90 days).

Scenario reflections

Scenario A. A teammate says “I always commit directly to main on this project.” Without writing code, walk through one concrete situation where that habit would create a problem they did not anticipate.

Show answer

Concrete situation where always-commit-to-main creates a problem: your teammate (or you, two weeks from now) starts working on top of your in-progress main commits. They pull main, get your half-finished work, build on top of it. Now neither of you can safely revert your half-finished commits without also unwinding the teammate’s good work. The branch model would have kept your in-progress work isolated; pull would not have brought your unfinished state to teammates. Other scenarios: deploying main directly to production with half-finished features visible; CI breaking on commits that are intentionally incomplete; merge conflicts on remote-pushed work-in-progress.

Scenario B. A new developer asks: “If branches are cheap, why doesn’t every commit get its own branch?” Without writing code, explain the cost-vs-benefit tradeoff that determines when a branch is appropriate.

Show answer

The cost-vs-benefit tradeoff: a branch has a small fixed cost (the name, the discipline to keep track of which branch you’re on, the eventual deletion or merge). The benefit of a branch is isolation: your work doesn’t touch other people’s work until you decide to merge. For changes large enough that isolation matters (anything reviewed, anything that could have its own lifecycle), the benefit exceeds the cost. For changes too small to need isolation (typo fixes, formatting), the cost exceeds the benefit. There isn’t a sharp boundary; teams develop intuition. A reasonable starter rule: if the change is something a reviewer would want to see as a discrete unit, branch it. If not, commit directly.

Scenario C. A team’s git branch -a lists 87 branches. Most have not been touched in 3+ months. What does this tell you about the team’s process, and what would you suggest as a first cleanup step?

Show answer

87 branches with 3+ months of inactivity tells you the team has process gaps: PRs are not getting reviewed promptly (work pools on branches), branch deletion after merge isn’t happening (so merged branches sit around), or experiments / spikes / one-off branches are not getting cleaned up. First cleanup step: identify the merged-but-not-deleted branches (git branch --merged main) and bulk-delete them (git branch --merged main | grep -v main | xargs git branch -d is the unsafe-feeling but standard approach; do it in a safe sandbox first). After the merged ones are gone, sort the remaining by last-commit-date and triage the stale ones with their authors. Many will be abandoned and can be deleted; some will be paused work that needs to be either resumed or formally abandoned.

Flashcards

Q. What is a branch in git?

A movable pointer to a commit. Not a copy of the code. Not a folder. Just a label that points to a node in the snapshot graph.

Q. What is HEAD?

A special pointer to your current branch. When you commit, the branch HEAD points to moves forward.

Q. What command creates a new branch AND switches to it?

git switch -c <branch-name> (modern) or git checkout -b <branch-name> (older). Both work.

Q. What command switches to an existing branch?

git switch <branch-name> (modern) or git checkout <branch-name> (older). Both work.

Q. What command lists branches?

git branch (local only). git branch -r (remote-tracking only). git branch -a (all).

Q. What is the difference between git branch -d and git branch -D?

Lowercase -d is safe (refuses if branch has unmerged work). Uppercase -D is forceful (deletes regardless). Prefer -d.

Q. Why are git branches considered cheap?

Creating a branch is one filesystem write (a small pointer file). No code is copied. Switching is fast because the working directory is just repopulated from the target snapshot.

Q. What does cheap-branches enable that older VCS couldn't?

Branch-per-feature workflows. Pull request reviews on every unit of work. Free experimentation (a failed experiment is “delete the branch”). The whole modern git collaboration model.

Q. What is the common naming convention for branches?

<type>/<short-description>. Examples: feature/payment-flow, bugfix/login-redirect, hotfix/critical-issue. Pick a convention; be consistent.

Q. When should you branch, and when should you commit directly to your current branch?

Branch for separable units of work, experiments, context switches, anything that will be reviewed before landing. Commit directly for one-line typo fixes in solo work, or when you are on a series of related commits that should land together.