branch
Also called: branches
A named, movable line of commits: a parallel version of the project where work happens without touching the main branch.
A branch lets someone work on a change without disturbing everyone else. It starts from a commit on the main branch and collects new commits of its own. When the work is ready, the branch is merged back, usually through a pull request. Branch names often describe the work: fix/checkout-button, feature/subscription.
Learn it in the course
- Branches: parallel versions of the project · What a branch is, why work happens on short-lived branches next to main, and how to read branches on GitHub: the branch selector, ahead and behind, stale branches and graphs with several lanes.
- Merge conflicts: why they happen and what to do · Why two branches can clash on the same line, what GitHub shows when they do, how to read conflict markers and resolve a simple conflict in the browser, and why choosing the right text is a product decision.
- Merging: merge commit, squash and rebase on GitHub · What merging does, the three options behind GitHub's merge button and what each leaves in the history, fast-forward in plain words, and how to check whether a change is really in main.
- Icons and colours: what every state means · Read pull requests, issues, checks, reviews, labels and the merge box at a glance: what every GitHub icon and colour means, and how to tell states apart by shape and text, not colour alone.
- GitHub flow: small branches, fast merges · The loop most product teams work in: branch from main, pull request, review and checks, merge, deploy. Why small, short-lived branches are safer, what "merged" and "deployed" mean, how feature flags let unfinished work ship hidden, and how to read a feature's progress from the pull request list.