Study notes · 9% of the exam

Pull Requests, Reviews and Team Workflows

Pick a branching model that matches how you ship, route every change through small, well-described pull requests, and let branch protection, CODEOWNERS and conventions enforce the team's rules automatically.

Key points

1
GitHub Flow keeps one always-deployable main with short PR branches; GitFlow adds develop, release/* and hotfix/* for scheduled versions; trunk-based development integrates daily behind feature flags.
2
Merge methods shape history: a merge commit keeps original SHAs, squash makes one commit per PR, and rebase and merge replays each commit with new SHAs.
3
Closing keywords (fixes, closes, resolves and their variants) close issues only when the PR targets the default branch, and each issue needs its own keyword.
4
CODEOWNERS: the last matching pattern wins, owners need write access, and drafts don't request owners until marked ready.
5
Branch protection can require reviews, status checks, linear history and conversation resolution; stale approvals can be dismissed when the diff changes, and a merge queue keeps busy branches green.
6
Conventional Commits map fix to PATCH, feat to MINOR, and ! or a BREAKING CHANGE: footer to MAJOR.
7
Repository roles run Read < Triage < Write < Maintain < Admin; Triage manages issues and PRs without code write access.

Common traps

Fixes #34, #35 closes only #34; repeat the keyword for every issue.
Squash-merging a branch you keep working on makes later PRs repeat already-merged commits and conflicts.
Rebasing or force-pushing a shared PR branch disrupts teammates; merge the base into it instead.

Read the source

Test yourself on Pull Requests, Reviews and Team Workflows

Ten questions, with the answer and explanation after each one.