git-workflow

A dev-first branching model routes feature development through a dev branch before main, while an insiders preview channel publishes early builds. This workflow accelerates feature delivery and reduces integration pain by standardizing branch flows across squads.

Structure Git branch naming conventions using a squad-based format like squad/{issue-number}-{slug}. This enforces a structured pull request lifecycle and coordinates multi-issue workspaces when paired with git worktrees.

Use git worktrees to manage multi-issue coordination by creating isolated working directories for different branches. This supports cross-repo workflows and allows simultaneous development without constantly switching branches in a single directory.

Yes, this Git workflow supports release coordination by establishing a three-branch model with main, dev, and insiders branches. It defines specific publication flows to standardize releases and manage cross-repo collaboration among different squads.

You should avoid a dev-first branching model if your project does not require strict release coordination or multi-squad governance. It enforces structured PR workflows and branch naming conventions that may introduce unnecessary overhead for small, simple repositories.

Automate Git workflow governance by enforcing a structured PR lifecycle alongside a dev-first branching model. This requires adherence to branch naming conventions and defined publication flows between main, dev, and insiders branches to standardize integration.