Git workflows for teams

This chapter follows Code review and pull request hygiene.

A workflow is the team’s agreement about branch lifetimes, where releases are cut, and who integrates work. Git commands are the same everywhere; the workflow decides how often you merge and how much parallel history you tolerate.

Team size and integration load

Contributors propose changes; maintainers merge to protected refs. As headcount grows, narrow merge rights matter more than fancy branch names.

flowchart LR
  subgraph medium [Medium team]
    C1[Contributor]
    C2[Contributor]
    MA[Maintainer]
    C1 -->|PR| MA
    C2 -->|PR| MA
  end

Benevolent dictator and lieutenants

Large open-source efforts (Linux-style) use subsystem maintainers who review patches and forward accepted work upstream. GitHub’s fork + PR model matches the contributor side; lieutenant structure is organizational, not a Git feature.

Branch types and lifetime

Long-lived branches defer merge pain and increase merge pain when you finally integrate. Workflows pick how much deferral you accept.

Why feature branches still matter

Even with strong CI, isolated branches help you:

• Review and revert one feature without touching unrelated commits
• Experiment without polluting main
• Run CI on the branch before integration

Pair feature branches with short lifetime and frequent merges from trunk—see trunk-based development below.

Trunk-based development

Trunk-based development (TBD) keeps one long-lived main. Developers integrate small changes frequently—often daily—with optional short release branches.

Requirements:

• Commits small enough to review quickly
• main always buildable; broken builds are top priority
• CI blocks bad merges; feature flags hide incomplete work

gitGraph
  commit id: "c1"
  commit id: "c2"
  commit id: "c3"
  commit id: "c4"

TBD fits SaaS with continuous deployment and mature automation (GitHub Actions).

Release branches on trunk

Some trunk teams cut release/1.2 briefly for stabilization while main continues. Only bugfixes land on the release branch; merges back to main keep lines aligned.

Git Flow

Git Flow uses main (production history) and develop (integration). Features merge to develop; release branches bake versions; hotfix branches patch main and sync to develop.

gitGraph
  commit id: "init"
  branch develop
  checkout develop
  commit id: "d1"
  branch feature
  checkout feature
  commit id: "f1"
  checkout develop
  merge feature
  branch release
  checkout release
  commit id: "rc1"
  checkout main
  merge release id: "v1"
  checkout develop
  merge release

Suited to scheduled versioned releases and teams that want explicit release stabilization. Cost: merge overhead between develop, main, and long-lived features.

git-flow scripts (optional)

The git-flow AVH extension wraps branch start/finish:

1
git flow init
2
git flow feature start login
3
git flow feature finish login

The same results come from git switch, merge, and tag. Many new repos document branch names in CONTRIBUTING.md instead of installing the extension.

Plain-Git release outline:

1
git switch develop
2
git switch -c release/1.2
3
# stabilize on release/1.2
4
git switch main && git merge release/1.2 && git tag v1.2.0
5
git switch develop && git merge release/1.2

GitHub Flow

GitHub Flow targets services deployed from main:

1. Branch from main
2. Open PR; iterate with review and CI
3. Merge to main
4. Deploy main (or auto-deploy on merge)

No required develop. Production may track main directly or via environment tags. Fits code review hygiene and protected main.

Monorepos and multiple teams

One repository with many packages/services adds path ownership (CODEOWNERS) and often per-area CI (only run tests for changed paths). Workflow choice still applies: trunk vs release branches, but merge queues and required checks become critical at scale.

Avoid long-lived integration branches per team unless you accept regular painful merges into main.

Open source defaults

Typical pattern:

• main protected; all work via PR
• Fork for drive-by contributors; branch push for core team
• Maintainer merge + tag for releases
• Document security reporting outside public issues

See Collaborating with Git for fork upstream sync.

Choosing and documenting a workflow

Write down branch names, merge strategy, required checks, and hotfix steps. Link Merging versus rebasing so everyone knows whether shared history may be rewritten.

Next: GitHub Actions.