Choosing a Strategy

Updated

October 30, 2026

Choosing a Strategy

After this page you can write a short default for desk-api and know where this book will enforce it later.

 versions in the wild? ── yes ──► Git Flow (main + develop + release/*)
        │
        no
        ▼
 several merges/day + flags? ── yes ──► trunk-based
        │
        no
        ▼
 GitHub Flow     short feat/* off main     ← desk default

A default for this book’s desk

  • Topology: GitHub Flow — short feat/ / fix/ branches off main, delete after integrate
  • Integrate: rebase the feature onto main, then --ff-only or a forge squash
  • main: always deployable; revert to undo (never rebase published main)
  • Repos: polyrepo (desk-web, desk-api, desk-infra) until a chapter says otherwise
  • Host: Linux; hooks and CI run there first

Write it in README.md or CONTRIBUTING.md in the repo. A strategy that exists only in someone’s head is not a strategy.

When to change it

  • Multiple supported versions in production → Git Flow release branches
  • Several merges to main per engineer per day and strong tests → trunk-based plus flags
  • One PR always touches all three desks → consider a monorepo
  • A compliance officer needs a merge commit per change → --no-ff on main

What Git will not decide

Git will merge whatever you ask. Forges add buttons (squash, rebase, merge). Chapter 31 is branch protection, code owners, required checks. This chapter is the agreement. The next part (power skills) is internals, reflog, bisect, and repair — the tools you want when the agreement meets a bad Tuesday.