Repository Strategies

How you organize your source code repositories and enforce collaboration rules directly shapes how your CI/CD pipelines behave. A branching model that keeps code isolated for weeks cannot support Continuous Integration - by definition.

---

Branching Strategies

Branching strategies define when to create branches, how long they should live, and how they are merged back. The goal is always the same: keep the main branch deployable at all times while enabling parallel development.

Most workflows are built from a small set of standard branch archetypes:

Branch Type	Purpose	Lifecycle
Main (main / master)	The single source of truth. Must always be stable and deployable. Everything branches from it and merges back to it.	Permanent
Feature	Isolates development of a specific feature or fix until it is complete, reviewed, and passes tests.	Short-lived (hours to a few days)
Release	Prepares a specific version for production. Only bug fixes allowed - never new features. Tagged with a version number on merge.	Temporary (until the release ships)
Hotfix	Addresses critical production bugs with urgency. Branched from the live tag on main; merged back into both main and any active develop branch.	Extremely short-lived
Development	Integration branch that collects multiple feature branches before they reach main. Common in legacy GitFlow.	Long-lived (if used at all)

The Three Major Branching Workflows

The three dominant branching workflows sit at different points on the integration spectrum - from most continuous to most structured:

	Trunk-Based Development	GitLab Flow	GitFlow
Core idea	Integrate directly to main multiple times per day	main as working branch, with environment-named branches (Production, Preprod)	Separate develop branch + long-lived release/hotfix branches
Branch lifetime	Hours (or direct to trunk)	Short to medium	Days to weeks
Integration risk	Low - small, frequent diffs	Medium	High - large merges with conflicts
CI/CD compatibility	Continuous Deployment	Continuous Delivery	Continuous Delivery
Best for	SaaS, high-velocity teams	Teams needing environment promotion gates	Versioned products, regulated releases

Tip

If a feature branch lives longer than one day, it is drifting from main. The longer it diverges, the harder the eventual merge. In Trunk-Based Development, this is solved with feature flags - the code merges daily, the feature is just toggled off until it’s ready.

Delivery Branching Patterns

Beyond the overall workflow, teams also layer specific delivery patterns on top. The choice should match the deployment model, not just developer preference:

Pattern	How it works	Best paired with
Task branching	One short-lived branch per task, merged immediately on completion	Trunk-Based Development
Feature branching	Branch per feature, merged when the feature is fully ready	Microservices, GitLab Flow
Release (version) branching	Dedicated branch per shipped version, used to isolate fixes for that version	GitFlow, packaged software

---

Monorepo vs Polyrepo

The repository model you choose determines how services relate to each other, how pipelines are triggered, and how teams coordinate.

	Monorepo	Polyrepo
What it is	All services and libraries live in one repository	Each service has its own independent repository
Atomic changes	✅ A single commit can span multiple services	❌ Cross-service changes require coordinated PRs
Pipeline complexity	High - pipelines must detect which sub-paths changed	Low - each repo has a simple, focused pipeline
Dependency visibility	✅ Internal dependencies are always in sync	❌ Version mismatches between repos cause integration pain
Tooling requirement	Requires Nx, Bazel, or Turborepo for change detection & caching	Standard tooling works out of the box
Used by	Google, Meta, Uber, Twitter	Most small-to-medium engineering teams

The right choice depends on organizational size and team structure. Teams with many independent microservices often start with polyrepo and migrate toward monorepo as cross-service coordination overhead grows.

Microservices Repository Patterns

Distributed microservices architectures have specific requirements. There are three common approaches, each with a different scope of isolation:

Pattern	Structure	CI/CD implication
Full separation	Every microservice has its own dedicated repo and its own pipelines	Maximum independence; cross-service changes require coordinated releases
Separation by service type	Related services (e.g., user management, payments) share one repo	Simplifies shared database and config management; still keeps domains isolated
No separation (Monorepo)	All microservice code lives in a single repo	Atomic cross-service commits; requires change-detection tooling to avoid rebuilding everything on every push

Note

In a monorepo setup, pipelines should use path-filtered triggers. A change to services/auth/** should only trigger the auth service pipeline - not the entire codebase. Without this, every commit builds everything, which is unsustainable at scale.