Design and implement a source control strategy
Choose a strategy, then enforce it
Match branching to release cadence. Trunk-based development keeps main releasable, uses short-lived feature branches, feature flags and fast merges - the right pick for continuous delivery. GitHub Flow adds a pull-request review loop on top of the same idea. Release branching or GitFlow keeps develop, release/* and hotfix/* alive; choose it only when several shipped versions must be serviced in parallel.
Branch policies and protection
Policies do the enforcing: require a minimum number of reviewers, check for linked work items, require comment resolution, build validation (a pipeline that must succeed), status checks from external services, limit merge types, and automatically include reviewers. Required reviewers with a path filter are how you force a security or database owner to review /**/security/**. Bypass permissions let a group skip policies - a classic trap: policies alone do not stop administrators.
Repository topology
Branches live inside one repository; forks create a separate copy, which is why open-source and external-contributor models use forks. Monorepo versus multi-repo trades atomic cross-service changes against independent build and release cadence. Use Git LFS for large binaries and make sure agents have it installed. .gitignore and .gitattributes are part of the strategy, not an afterthought.
Traps
- "Prevent direct pushes to main" → branch policies on
main, plus removal of bypass rights. - "Keep history linear" → squash merge, accepting that individual commits are collapsed away.
- Migrating TFVC history is a conversion, not a clone.
Rule of thumb
Trunk-based with feature flags by default; release branches only when you must patch a version you already shipped.