git-workflow

A structured Git workflow for multi-repo projects uses a three-branch model (main, dev, insiders) to coordinate integration and releases. This enforces branch naming conventions and a promotion pipeline, producing CI-ready releases while minimizing drift between development and production.

Managing parallel feature branches across multiple repositories is best handled using Git worktrees for isolated environments. Coordinated cross-repo scenarios rely on an issue-focused workflow, branching from dev with traceable names like squad/{issue-number}-{slug} to synchronize parallel development.

You need an insiders branch in your release pipeline when providing an early-access channel synced from dev. It sits alongside main for tagged production releases and dev for feature integration, allowing teams to publish preview tags before promoting code to the final release.

To prevent merge conflicts when integrating squad features into dev, apply a strict issue-focused workflow. Features branch from dev using standard naming conventions, draft PRs are reviewed, and merges follow a defined promotion pipeline with anti-pattern guidance to avoid conflicts and drift.

This Git branching model targets squad-based teams handling multi-issue, multi-repo projects rather than single-developer repositories. Its dev-first release strategy, worktree coordination, and three-branch promotion pipeline are designed specifically to structure coordinated feature development and safe releases.

A three-branch Git workflow distinguishes itself from standard GitFlow by enforcing a dev-first release approach with a dedicated insiders early-access channel. It reduces merge conflicts and drift by strictly separating tagged production code in main, integration in dev, and early previews in insiders.