Practice merge and pull request vocabulary: draft PRs, CI failures, review states, merge strategies, CODEOWNERS approval requirements, and rebase before merge.
0 / 5 completed
1 / 5
'Draft PR for early feedback.' What is the purpose of a draft (or WIP) pull request?
Draft pull requests (GitHub) or WIP merge requests (GitLab) signal 'work in progress — not ready to merge'. They enable early collaboration: reviewers can comment on the approach, flag potential issues, and give design feedback while changes are still easy to make. Drafts prevent accidental merges and communicate status clearly. Convert to 'ready for review' when the implementation is complete.
2 / 5
'The PR is blocked by CI failure.' What does a CI failure on a PR mean?
CI (Continuous Integration) runs automatically on every PR — typically running tests, linters, type checkers, and build steps. A CI failure means one of these checks failed. Most repositories are configured to block merges until CI passes, ensuring broken code doesn't reach the main branch. The PR author must fix the failure and push new commits to re-trigger CI.
3 / 5
What is the difference between 'squash and merge' and 'merge commit'?
Squash and merge collapses all commits from the PR into a single, clean commit on main — ideal for keeping main history readable. Merge commit (a traditional merge) creates a merge commit and preserves all individual commits from the branch. The choice depends on team preference: squash produces a cleaner linear history; merge commits preserve the full context of how the feature was developed.
4 / 5
'The PR requires 2 approvals from CODEOWNERS.' What is a CODEOWNERS file?
CODEOWNERS (GitHub/GitLab) is a file that defines automatic review requirements based on which files are changed. If you touch /src/payments/, the payments team is automatically added as required reviewers. This ensures domain experts review changes to their areas of the codebase. The CODEOWNERS file sits in the repository root or .github directory.
5 / 5
'The PR is rebased on main before merging.' What does rebasing a PR branch on main do?
Rebasing the PR branch on main replays your commits on top of the current main branch tip. This ensures: (1) your changes incorporate all recent main branch updates, (2) any conflicts are resolved by you (who best understands the PR context) rather than during merge, and (3) CI runs against the combined code before merge. It produces a cleaner linear history compared to merge commits on feature branches.