Collaboration at Scale#

When teams grow beyond a handful of developers, Git workflows become critical infrastructure. The right workflow reduces merge conflicts, accelerates delivery, and preserves code quality. The wrong one creates bottlenecks and frustration.

Git Workflows Compared#

GitFlow#

main ─────────●─────────────────●──────────── (releases)
               ╲               ╱
develop ────●───●───●───●───●─●──────────── (integration)
             ╲     ╱   ╲   ╱
feature/x ────●───●     ╲ ╱
                     feature/y ──●

GitHub Flow#

main ─────●──────●──────●──────●──────── (always deployable)
           ╲    ╱  ╲   ╱  ╲   ╱
feature ────●──●    ●──●    ●──●
            PR+CI   PR+CI   PR+CI

Trunk-Based Development#

main ──●──●──●──●──●──●──●──●──●──── (everyone commits here)
        │  │     │        │
        small    small    small
        commits  commits  commits

Ship / Show / Ask#

A nuanced model that categorizes changes by risk:

Comparison Table#

Large Repository Strategies#

Monorepo#

All code in a single repository:

monorepo/
├── services/
│   ├── orders/
│   ├── payments/
│   └── inventory/
├── libraries/
│   ├── shared-auth/
│   └── common-types/
└── infrastructure/
    └── terraform/

Tools: Nx, Turborepo, Bazel, Pants, Rush

Sparse Checkout (Git native)#

# Only check out what your team needs
git sparse-checkout init --cone
git sparse-checkout set services/orders libraries/shared-auth

Git Submodules / Subtrees#

Signed Commits#

Verify that commits genuinely came from the claimed author:

# Setup GPG signing
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true

# Sign a commit
git commit -S -m "feat: add payment validation"

# Verify
git log --show-signature
# gpg: Signature made ... using RSA key ID ABC123
# gpg: Good signature from "Developer Name <dev@example.com>"

SSH Signing (Git 2.34+)#

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub

Enforcement#

Merge Queues#

Merge queues solve the “semantic conflict” problem: two PRs pass CI individually but break when combined.

The Problem#

PR #1 passes CI  ✓  (changes function signature)
PR #2 passes CI  ✓  (calls function with old signature)
Both merge → main is broken ✗

How Merge Queues Work#

PR #1 ──→ ┌─────────────┐
           │ Merge Queue │ → Test (main + PR#1 + PR#2) → Merge both
PR #2 ──→ └─────────────┘                              or reject PR#2

1. PR is approved and added to the queue
2. Queue creates a speculative merge (main + all queued PRs)
3. CI runs on the combined result
4. If it passes, all queued PRs merge; if not, the failing PR is ejected

Code Review Automation#

CODEOWNERS#

Automatically assign reviewers based on file paths:

# .github/CODEOWNERS (GitHub) or CODEOWNERS (GitLab)

# Global default
*                       @team-leads

# Service-specific ownership
/services/orders/       @orders-team
/services/payments/     @payments-team @security-team

# Infrastructure requires platform team
/infrastructure/        @platform-team
*.tf                    @platform-team

# Documentation — anyone can review
/docs/                  @tech-writers

# Security-sensitive files need security review
/auth/                  @security-team
**/secrets*             @security-team

Automated Checks#

Review Policies#

# Example: GitLab merge request approval rules
approvals_required: 2
rules:
  - name: "Security Review"
    approvals_required: 1
    groups: ["security-team"]
    applies_to: ["auth/**", "*.tf"]
  - name: "Standard Review"
    approvals_required: 1
    groups: ["developers"]

PR Size Guidelines#

Rule of thumb: If a PR takes more than 30 minutes to review, it’s too large. Reviewers lose attention after ~400 lines.

Scaling Practices Summary#

Key Takeaways#

1. Trunk-based development scales best for high-performing teams — short-lived branches and feature flags replace complex branching models.
2. GitHub Flow is the pragmatic middle ground for most teams.
3. Merge queues prevent the “passing individually, failing together” problem.
4. CODEOWNERS ensures the right people review the right code automatically.
5. Signed commits prove authorship — essential for supply-chain security.
6. Keep PRs small (< 200 lines) — review quality drops dramatically with size.
7. The best workflow is the one your team actually follows — complexity kills adoption.