Theory

Updated

October 30, 2026

Theory: A Workflow is a Policy on Names, Not a Git Feature

Git Flow, GitHub Flow, and trunk-based development are agreements about which refs are long-lived, how long a feature name lives, and how main stays deployable. Git will merge whatever you ask. The workflow is which asks you allow.

Invariants

  1. Long-lived branches diverge; every extra one is a merge or rebase tax.
  2. Short-lived feat/* off main (GitHub Flow topology) is independent of GitHub the product.
  3. Trunk-based requires runtime flags or very small commits so main can take unfinished code.
  4. Monorepo vs polyrepo is a repository boundary decision; worktrees still apply; submodules usually do not in a monorepo.
 Git Flow          main + develop + release/*     high ceremony
 GitHub Flow       main + short feat/*            this book’s desk default
 Trunk-based       main + flags                   high CI, tiny commits

Why write it down

A strategy that exists only in chat is not enforceable. Chapter 31 (governance) is how a forge requires reviews and checks. This chapter is the graph you are asking Git to keep.

What can break

  • Git Flow on a two-person desk-api (ceremony without versions in the wild).
  • Trunk-based without tests or flags.
  • A monorepo whose CI always builds everything.

How to read this chapter

Git Flow, GitHub Flow/trunk, flags, mono/poly, choosing; then forking, stacked changes, release tags.