Branch

A movable name for one line of Git history, allowing several sequences of commits to exist in the same repository before they are merged or otherwise reconciled.

A Git branch points to a chain of commits. New commits advance the branch you are on while other branches keep pointing to their own histories. This lets a team develop two changes in parallel or run a pull-request workflow without mixing unfinished commits. A branch does not create a separate filesystem by itself, protect the live site, or prevent shared-state conflicts. Deployment configuration decides what reaches users, and a worktree or separate checkout provides simultaneous working directories.

Builder example

Branches are useful when the repository's delivery process is organized around pull requests, parallel contributors, or release lines. They also add merging and stale-base work. A one-person repository may intentionally work directly on main, while an automated system may require a branch for every change. The correct choice comes from the repository's written delivery contract, not from AI involvement or feature size alone.

Common confusion: Committing on one branch does not advance another branch, but the same working directory can still contain uncommitted files when you switch. A branch is version-history isolation; a worktree is a separate checkout; deployment is a different system again.