2.1.4.1. Branching Models: Trunk-Based, GitHub Flow, and GitFlow
2.1.4.1. Branching Models: Trunk-Based, GitHub Flow, and GitFlow
Branching strategy determines how code flows from developer to production. Trunk-based development — where developers commit small changes directly to main, often behind feature flags — minimizes merge conflicts and enables continuous integration. GitHub Flow adds lightweight feature branches merged through pull requests, suitable for teams that value code review before integration. GitFlow uses long-lived develop and release branches, appropriate for packaged software with multiple supported versions but often too heavyweight for SaaS. The key insight: shorter-lived branches mean fewer conflicts. Every day a branch stays open, the main branch diverges further. Azure Repos branch policies enforce quality server-side — minimum reviewers, build validation, comment resolution, and work item linking — physically preventing merges that don't meet standards.
Branch naming conventions improve automation and readability. Prefixes like feature/, bugfix/, hotfix/, and release/ enable path-based pipeline triggers and communicate intent. Azure Repos supports hierarchical branch organization: feature/auth/oauth-refresh nests under feature/auth/, making large repositories navigable.
Pull request workflows enforce quality through automation. Required reviewers can be set per path — changes to /infrastructure/ require platform team review, while /api/ changes require backend team review. Auto-complete eliminates merge ceremony: the developer sets it when creating the PR, and merge happens automatically once all policies pass. PR templates standardize what reviewers need to assess — a checklist of "tests added," "docs updated," "breaking changes documented."
For monorepos, CODEOWNERS files assign reviewers automatically based on changed paths, ensuring the right experts review the right code without manual assignment.
Merge strategies affect history and conflict resolution. Merge commits preserve branching history (useful for understanding when features were integrated). Squash merges compress a feature branch into a single commit (cleaner history, harder to debug individual changes). Rebase and fast-forward create linear history (cleanest, but rewrites commits).
Azure Repos enforces merge strategy per branch through branch policies: require squash merges for feature branches into main, allow merge commits for release branches. This creates a clean mainline while preserving detailed development history on feature branches when needed for post-merge debugging.
Fork-based workflows separate contributor permissions from maintainer permissions. External contributors fork the repository, push to their fork, and submit cross-repository pull requests. The maintainer reviews the PR without granting the contributor write access to the main repository. This is the standard model for open-source collaboration and can also serve internal teams with strict access controls between organizational units.
Pull request workflows are the enforcement mechanism for branching policies. Azure Repos auto-complete eliminates merge ceremony — developers set auto-complete when creating the PR, and merge happens automatically the moment all policies pass without requiring a manual "Complete" click. Squash merging condenses feature branch commits into a single commit on main, simplifying history at the cost of losing individual commit detail. Semi-linear merge (rebase + merge commit) preserves individual commits while maintaining a clean graph structure.
The choice between merge strategies — merge commit, squash, and rebase — affects traceability and history readability differently for each team workflow.
