foundation

Branch

Use branch references as movable names over commits for isolated work, review, release, and experiment flows.

A branch is a movable reference (pointer) to a commit — not a copy of files. Creating `feature/login` costs one ref update; the commit graph is shared.

					git switch -c feature/login
git branch -vv          # local branches + upstream tracking
git fetch origin        # update remote-tracking refs only
				

Branches enable parallel work, but integration cost grows with divergence. Remote-tracking branches (`origin/main`) reflect last-fetched server state — not necessarily what teammates just pushed.

On interviews: describe branch pointers, remote-tracking refs, mainline policy, and why short-lived branches reduce integration risk.

Common pitfalls: long-lived branches that hide conflicts and design drift; assuming local `main` matches `origin/main` without fetch; branch naming as a substitute for small changes and CI.

The trade-off is isolation (feature branches) versus frequent integration (trunk-based) — match policy to release cadence and test maturity.

Checklist:

  • Treat branches as commit refs, not file copies.
  • Fetch before reasoning about shared state.
  • Prefer frequent integration for active work.
  • Keep default branch protected and deployable.