Skip to content

Branches as parallel work surfaces

L5 opens Phase 2 by teaching what a branch is and why it matters. The mechanics from Phase 1 give a learner solo workflow. L5 adds the primitive that makes collaboration possible.

Three load-bearing ideas:

  1. A branch is a movable pointer to a commit, not a copy of the code. This single insight unlocks every later git topic. Once you see branches as labels on the snapshot graph, merges, conflicts, remotes, and pull requests all become operations on the same graph.

  2. Branches are cheap, and that cheapness is git’s defining innovation. SVN-trained instincts are wrong here. In git, branch liberally. Every unit of work deserves its own branch.

  3. HEAD is the pointer to your current branch. When you commit, the branch HEAD points to moves forward. Switching branches is moving HEAD to a different label.

By the end of L5, the reader will be able to

Section titled “By the end of L5, the reader will be able to”
  • Explain what a branch is in terms of the snapshot graph from L1
  • Create a branch with git switch -c <name> (modern) or git checkout -b <name> (older)
  • Switch between branches with git switch <name>
  • List branches with git branch and recognize the asterisk-marked current branch
  • Delete merged branches safely with git branch -d <name>
  • Recognize what HEAD points to and why that matters
  • Choose between “branch this” and “commit directly to main” based on context
  • Articulate why git branches are cheap and what that enables
  • L1 (snapshot mental model)
  • L2 (three-area model, basic commits)
  • L3 (commit hygiene)
  • L4 (undoing things): the recovery toolkit is useful when experimenting with branches
  • A real repository to practice on

L5 is the conceptual entrance to Phase 2. The diagrams in the lesson body are load-bearing: if a reader internalizes the diagram of two branches diverging at commit D, they have the mental model for everything else in Phase 2.

New developers should focus on the diagrams plus the practice section. Experienced developers should focus on the “when to branch / when not to” section and the “for managers and TPMs” framing.

Managers and TPMs should read the dedicated framing section. The “branch hygiene predicts team velocity” observation is operationally useful.

What this lesson deliberately does not cover

Section titled “What this lesson deliberately does not cover”
  • Merging branches together (deferred to L6 + L7)
  • Pull requests on GitHub / GitLab (deferred to L6)
  • Resolving merge conflicts (deferred to L7)
  • Remote branches and the difference between local and remote (deferred to L8)
  • Rebasing (deferred to L12)
  • Cherry-picking commits between branches (deferred to L11)
  • Branch protection rules and CI gates (deferred to L9)

If you find yourself wanting to merge a branch back into main, L6 is the right next read. If you hit a conflict while merging, L7. If you want to push a branch to GitHub, L8.

20-25 minutes for reading (the diagrams take time to absorb). 15-20 minutes for the practice exercises (includes a “create three branches, switch between them, see how HEAD moves” drill that builds muscle memory).

Total: about 35-45 minutes including practice.