The AZ-400 exam's source control section asks how teams split, merge, and protect code. It covers branching strategy trade-offs, Pull Request policy configuration, and repository platform differences. One wrong branching strategy can cascade into a deployment crisis; a single missing PR policy can let a security vulnerability reach main. Source control strategy is the foundation every DevOps pipeline builds on.
Branching Strategies: The Blueprint for How Teams Collaborate
Imagine two people trying to borrow the same library book at the same moment — without a clear checkout system, conflict is inevitable. Source code faces the same problem: when multiple developers modify the same file simultaneously, merge conflicts pile up. A branching strategy is the team's agreed system for minimizing those collisions and integrating changes safely.
uses five branch types: , , , , and . It suits teams with defined release schedules who maintain multiple live versions, like mobile apps supporting several OS versions. The trade-off is complexity: many long-lived branches make CI/CD automation harder.
uses only and short-lived branches. A developer opens a Pull Request from the feature branch and merges back into main after review. Fast and simple, best for small teams with frequent web deployments.
has every developer commit small changes directly to multiple times per day. Branches are so short-lived that merge conflicts almost never accumulate. The key enabler is Feature Flags: unfinished features ship hidden behind a toggle. On the AZ-400 exam, 'rapid release cadence' or 'deep CI integration' scenarios point to TBD.
is Microsoft's internal strategy — teams cut branches directly from main, deploy from there, and cherry-pick hotfixes from main into the release branch. Azure DevOps itself uses this approach.
| Strategy | Branch Count | Release Cadence | Team Size | |----------|-------------|-----------------|----------| | GitFlow | High | Periodic | Medium–Large | | GitHub Flow | Low | Continuous | Small–Medium | | Trunk-Based | Minimal | Continuous integration | Any | | Release Flow | Medium | Sprint-based | Large |
Branch Protection: Keeping main Safe from Accidental Breakage
A bank vault layers a combination lock, a biometric scanner, and a security guard — it does not rely on a single padlock. The branch deserves the same defense. If anyone can push directly to main, a typo or malicious commit can reach production immediately. Branch protection enforces conditions that must be met before any PR can merge.
In Azure Repos, sets the rules for protected branches.
: N approvals required before merge : a pipeline must pass before merge is allowed : enforces traceability to Azure Boards : restrict to Squash, Rebase, or Merge commit Disable to block self-approval
GitHub's provides equivalent controls.
: reviewer approval mandatory : CI results must be green : limits direct pushers : only GPG-signed commits accepted
Both platforms block force-push and branch deletion on protected branches by default.
PR Policies and CODEOWNERS
On a film set, the director is not the only authority — the director of photography owns every camera angle, the sound designer owns every audio detail. Code reviews work the same way: no single person can meaningfully review every file in a large repository. declares who is responsible for each part of the codebase.
Place a file in (GitHub) or the repo root (Azure DevOps) and map paths to owners.
When a PR touches a listed path, those owners are automatically added as reviewers. Enabling in the Branch Protection Rule means the PR cannot merge without their approval. Azure Repos supports the same concept through path-based in Branch Policy.
Merge strategy choice also shapes history cleanliness.
: preserves full feature branch history in main : collapses all feature commits into one on main — best when PR history is noisy : replays commits on top of main for a linear history
'Cluttered PR history' or 'keep main clean' on the AZ-400 exam means Squash merge.
Repository Structure and Git File Management
A shopping mall puts groceries, clothing, and electronics under one roof — convenient but complex to manage. Specialty stores are simpler to run but require extra travel. Code repository structure presents the same trade-off.
A holds all services and libraries in one repository. Code sharing is effortless and cross-service builds run in a single pipeline. The downside is repository size growth and longer CI times. Git LFS, Scalar, and sparse-checkout are essential for large monorepos.
A keeps each service or team in its own repository. Team autonomy is high and access control is naturally isolated, but updating shared libraries requires independent changes in every repository.
excludes build outputs, dependency folders like , and local files from Git tracking. defines per-file-type handling: line-ending normalization () and Git LFS routing (). 'Binary assets bloating repository size' on the exam points to Git LFS and .
Azure Repos vs GitHub: Choosing by Ecosystem
Choosing between iOS and Android usually comes down to ecosystem: iOS connects seamlessly with Apple devices, Android offers broader hardware choice. Azure Repos vs GitHub follows the same logic.
| Aspect | Azure Repos | GitHub | |--------|-------------|--------| | Native CI/CD | Azure Pipelines | GitHub Actions | | Identity | Azure AD, org policies | GitHub Org, SAML SSO | | On-premises | Azure DevOps Server | GitHub Enterprise Server | | Work tracking | Azure Boards | GitHub Issues/Projects |
!Azure Repos versus GitHub
Azure Repos is the natural fit for teams running Azure Pipelines, Azure Boards, and Azure Artifacts as a unified platform. GitHub's strengths are the open-source community, GitHub Copilot, and the GitHub Actions Marketplace. 'Maintain existing Azure DevOps environment' favors Azure Repos; 'open-source contribution' or 'GitHub Actions ecosystem' favors GitHub.
Exam Key Takeaways
"Rapid CI, single branch, short-lived commits" -- Trunk-Based Development "Multiple release versions, scheduled delivery" -- GitFlow "Force build pipeline to pass before PR merge" -- Build Validation (Branch Policy) "Auto-assign reviewers when specific paths change" -- CODEOWNERS "Collapse PR commit history into one commit on main" -- Squash merge "Block direct push to main in Azure Repos" -- Branch Policy minimum reviewers "Prevent force push in GitHub" -- Branch Protection Rule "Handle large binary files in a monorepo" -- Git LFS + .gitattributes "Exclude build artifacts and env files from tracking" -- .gitignore "Unified Azure ecosystem repository platform" -- Azure Repos "Open-source contribution, GitHub Actions Marketplace" -- GitHub "Enforce GPG-signed commits on protected branch" -- Require signed commits
GitFlow = periodic multi-version releases, Trunk-Based = continuous single-branch integration, CODEOWNERS = automatic path-based reviewer assignment.