Cheatsheet: Branches as parallel work surfaces

Voice anchor

Git stores snapshots. Every other command is just navigating those snapshots.

A branch is a label on the snapshot graph.

Command reference

Action	Modern	Older (still works)
Create + switch	git switch -c <name>	git checkout -b <name>
Switch existing	git switch <name>	git checkout <name>
Create without switching	git branch <name>	(same)
List local	git branch	(same)
List all	git branch -a	(same)
List remote-tracking	git branch -r	(same)
Safe delete	git branch -d <name>	(same)
Force delete	git branch -D <name>	(same)
Rename current branch	git branch -m <new-name>	(same)

The graph mental model

A ---- B ---- C ---- D
                     |\
                     | \
                     E  F
                     ^  ^
                     |  |
                  feature main

• Commit nodes are immutable snapshots
• Branch labels (main, feature) point to nodes
• HEAD points to whichever branch is currently checked out
• When you commit, the branch HEAD points to moves to the new node

Branch naming conventions

Common pattern: <type>/<description>

Type	Example
feature/	feature/payment-flow
bugfix/	bugfix/login-redirect
hotfix/	hotfix/critical-prod-issue
release/	release/v2.0
experiment/	experiment/new-prompt-strategy

Some teams prefix with username (jay/payment-flow). Pick one. Document in CONTRIBUTING.md.

When to branch (decision rule)

• Separable unit of work: branch
• Experiment: branch
• Context switch from current work: branch
• Will be code-reviewed: branch
• One-line typo fix on solo project: main directly
• Series of related commits that ship together: main directly

HEAD internals (useful to know)

cat .git/HEAD                       # shows the current branch reference
cat .git/refs/heads/main             # shows the commit SHA main points to
cat .git/refs/heads/feature/login    # shows the commit SHA the feature branch points to

HEAD is literally a file containing the name of your current branch. Branch files contain commit SHAs. Everything is plain text.

What’s in L6

L6 introduces Pull Requests, the workflow that takes “I have work on a branch” and turns it into “the team reviewed and merged my work.” You’ll learn the GitHub/GitLab PR flow, how to write a good PR description, how to handle review comments, and the merge-vs-squash-vs-rebase choices at the end. PRs are where modern engineering culture happens; they are the single most consequential surface in the developer experience.