Design and implement a source control strategy
Branching and Pull Request Governance
CoreChoose a branch topology that matches release cadence, then enforce pull-request validation and merge restrictions on protected targets.
Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.
Why this matters
Branching creates inventory and integration delay. Governance must preserve review and quality without turning every change into a long-lived coordination problem.
Must Know
- Trunk-based development keeps integration frequent and branches very short; incomplete behavior is commonly separated from deployment with feature flags.
- GitHub Flow uses short-lived branches and pull requests into a deployable main branch.
- Release branches are justified when multiple released versions need independent maintenance, not simply because a release exists.
- GitHub branch protection and Azure Repos branch policies can require pull requests, approving participants, successful checks or builds, and resolved comments.
- Merge restrictions select allowed history outcomes such as squash, merge commit, or rebase; permissions determine who can bypass or force-push.
- Apply controls to the target branch or pattern, and use cross-repository policy when the same Azure Repos rule must protect many repositories.
Compare and Distinguish
- Branch permission authorizes an action; protection or policy supplies conditions; a required status check provides evidence.
- Squash creates one new commit, rebase replays commits, and a merge commit preserves branch topology.
Scenario examples
- Scenario: Main deploys continuously. Think: short branches, protected pull requests, and feature flags rather than a permanent develop branch.
- Scenario: Every main branch needs the same build check. Think: an Azure DevOps cross-repository branch policy.
Exam traps
- A branch name convention does not enforce review or validation.
- Granting broad bypass rights silently removes the policy from the people most able to change production.
- Protecting source branches does not protect the target branch merge path.
Key takeaways
- Minimize branch lifetime unless the release lifecycle demands maintenance lines.
- Separate authorization, validation, and merge-history decisions.
- Audit emergency bypass and keep it narrower than ordinary contribution.
How it works
- A pull request proposes a target-branch update; policies evaluate required approvals and automated evidence before the server permits completion.
- Cross-repository policies apply common target-branch requirements without manually configuring each current and future repository.
Objects and administrative surfaces
- GitHub rulesets or branch protection, required reviews and checks, merge queue or merge-method settings, and bypass lists.
- Azure Repos branch policies, branch security, repository policies, build validation, and cross-repository policies.
When to use it
- Use release branches only when separate supported versions require independent fixes or stabilization.
Security and governance implications
- Protect policy editing, force push, direct update, and bypass permissions separately from ordinary repository contribution.
Troubleshooting signals
- If a merge bypasses an expected rule, inspect the exact branch match, policy applicability, user permissions, and completion method.
More detail
- Combine required reviews, comment resolution, build validation, status checks, and allowed merge methods at the target branch.
- Use feature flags to separate incomplete customer exposure from source integration when work should merge frequently.
- Treat bypass as a narrow audited permission for an emergency role, never as the default contributor path.
Ready for the quiz?
- When is a release branch justified?
- Which control blocks a direct push to main?
- Why does a required pull-request approval not replace build validation?
Related objectives
- D2.1.S1 — Design a branch strategy, including trunk-based, feature branch, and release branch
- D2.1.S2 — Design and implement a pull request workflow by using branch policies and branch protection rules
- D2.1.S3 — Implement branch merging restrictions by using branch policies and branch protection rules