git-workflow

A dev-first branching model routes feature work through a dedicated dev branch before main, ensuring code is integrated and tested centrally before release. It uses a three-branch structure to speed feature delivery and reduce risk on the main branch.

To structure issue-based git work, create squad-based issue branches directly from the dev branch. This model enforces standardized branch naming conventions to improve traceability and mandates PR-based merges back into the dev or insiders branches.

You need an insiders branch when preparing for safe releases and validating multi-issue worktrees. It acts as a pre-main promotion pipeline stage where code is stabilized and tested before the final merge to the main branch.

For cross-repo coordination, use multi-issue worktrees and align squad-based issue branches across repositories. The dev-first workflow provides explicit promotion rules to maintain alignment across teams and prevent risky merges during cross-repo feature delivery.

Common anti-patterns include bypassing the dev branch to merge directly into main, ignoring standardized branch naming conventions, and skipping the insiders promotion pipeline. The workflow enforces post-merge cleanup guidelines to prevent these risky merge scenarios.

Yes, this workflow explicitly supports PR-based merges. It codifies the PR lifecycle steps and post-merge cleanup guidelines into your existing process, applying a dev-first branching model to streamline feature work and reduce main branch risk.