A pull request (PR) proposes moving completed changes from a feature branch into the main branch. It creates a review point: peers discuss the change, approve it, and then merge it. Used with GitHub Flow, this keeps main deployable while work continues on feature branches. section 8.3.1
Figure 8.4 The GitHub Flow branching strategy
GitHub Flow places the pull request between feature-branch work and merging to main. section 8.3.1
A pull request can act as both a delivery gate and a control point:
- Trigger quality workflows when changes are proposed for main, including testing and security checks before acceptance. section 8.7
- Require approval before merging through branch protection rules, preventing direct changes to main. section 11.2
- Enforce the four-eyes principle, so another person reviews a change before it reaches production. section 8.3.1 section 11.0
- Apply rules to administrators as well, while relying on audit logs to expose branch-protection changes. section 11.2
Quality-gated merge
A developer compiles changes on a feature branch for fast feedback. When ready, they open a pull request; testing and security workflows assess the proposed change. After the checks and approval succeed, the PR merges to main, triggering container-image creation and publication. section 8.7
Figure 11.4 Branch protection rules
Branch protection settings illustrate how to require pull requests and approvals before merging to main. section 11.2
