Learn vocabulary for GitHub repository governance: branch protection rules, CODEOWNERS, required reviewers, merge strategies, and protected branches.
0 / 5 completed
1 / 5
What are 'branch protection rules' on GitHub?
Branch protection rules are configured in repository settings and apply to specific branches (e.g., main). Common rules include: require pull request reviews, require status checks to pass, prevent force pushes, and require linear history.
2 / 5
What is the CODEOWNERS file in a GitHub repository?
The CODEOWNERS file (placed in the root, docs/, or .github/ directory) uses pattern matching to map file paths to owners. When a PR touches a file owned by a team or user, they are automatically added as required reviewers.
3 / 5
What does 'this needs two approvals' mean in a GitHub workflow?
Branch protection rules can specify a minimum required number of approving reviews. 'This needs two approvals' means the team has configured the protected branch to require at least two distinct LGTM/approval reviews before the PR can be merged.
4 / 5
What is a 'squash merge' strategy, and when is it preferred?
Squash merge collapses all commits on the feature branch into one commit on the target branch. This keeps the main branch history clean and readable, trading off individual commit granularity for a linear, summarised history.
5 / 5
What is a 'protected branch' and how does it differ from a regular branch?
Protected branches enforce governance policies. The main or production branch is typically protected to ensure every change goes through review and CI. Without protection, any collaborator with write access could push directly, bypassing quality controls.