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.