What Git branching strategies are commonly used with GitOps?

GitOps repositories have different branching needs than application source repos. The goal is to map Git branches or folders to deployment environments cleanly, while keeping promotion paths easy to reason about.

Three strategies are common in practice:

1. Environment branches: Separate branches represent separate environments — main maps to production, staging to staging, develop to development. Promoting from dev to staging is a PR merge from develop to staging. Simple to understand but prone to long-lived divergence and merge conflicts as environments drift apart.
2. Directory-per-environment on a single branch (trunk-based): One main branch holds folders like envs/dev/, envs/staging/, envs/prod/. Kustomize overlays sit in each folder. Promotion is a PR that copies or patches the relevant image tag into the next environment's overlay. This avoids branch divergence and is the approach most commonly recommended for Flux and Argo CD setups.
3. Separate repos per environment: Dedicated repositories for dev, staging, and prod config. Provides the strictest separation (prod repo can have tighter branch-protection and access controls) but makes cross-environment changes (e.g., updating a shared base) more cumbersome.

For most teams, trunk-based development with Kustomize overlays is the pragmatic choice. A single PR flow touching overlays is easy to review and the Git history stays linear. The separation of the application source repo (where code lives) from the config repo (where deployment manifests live) is an orthogonal best practice that applies regardless of the branching strategy chosen.