How do you manage branches, pull requests, and branch policies in Azure DevOps Repos?

Think of branch policies like the rules at an airport security checkpoint. Everyone must go through the same process — show ID (linked work item), pass the scanner (build validation), and get cleared by an agent (code reviewer) — before entering the departure gate (merging to main). No exceptions, no shortcuts, regardless of seniority.

Azure DevOps branch policies are configured per branch or branch pattern (like main, release/*, or hotfix/*). The most critical policies are: minimum number of reviewers (typically 2 for main), build validation (a CI pipeline must pass), linked work items (traceability), comment resolution (all threads must be resolved), and merge strategy restrictions (squash-only or semi-linear). These policies cannot be bypassed by regular contributors — only users with 'Exempt from policy enforcement' permission can force-push or bypass.

Pull requests in Azure DevOps provide a rich review experience with file-by-file diffs, inline comments, suggestion blocks (that reviewers can create and authors can apply with one click), iteration tracking (showing what changed between review rounds), and auto-complete (which merges automatically once all policies are satisfied). Teams can set up required reviewers for specific paths — for example, requiring a security team member to approve changes to files matching /src/auth/* or Dockerfile patterns.

The branching strategy most teams adopt is trunk-based development with short-lived feature branches. Feature branches are created from main, developed for 1-3 days maximum, and merged back via pull request. Release branches are cut from main when stabilization is needed, and hotfix branches target both main and the active release branch.

The gotcha that catches teams is not configuring 'Reset code reviewer votes when there are new changes.' Without this, a reviewer can approve early, the author pushes breaking changes, and the PR merges with stale approval. Another common issue is build validation using a different pipeline than the one that deploys — teams should validate with the same pipeline that will run post-merge to catch integration issues early.