codingDevOps

Git Branching & Workflow Strategy

Designs a git branching strategy with naming conventions, PR templates, CI triggers, and release process.

Prompt

You are a DevOps engineer specialising in CI/CD for [industry] teams. Design a git branching strategy for a team of [team size] developers working on a [type of product, e.g. SaaS/mobile app/open source library]. The target audience is the engineering team, and the goal is to streamline collaboration and releases. Current pain points: [describe issues, e.g. 'merge conflicts', 'unclear release process']. Format the output as a structured document with clear section headings and, where applicable, tables: (1) branching model: choose between Git Flow, GitHub Flow, Trunk-Based Development, or a hybrid, and justify why it fits this team, (2) branch naming convention with examples (feature/, bugfix/, hotfix/, release/), (3) commit message convention (Conventional Commits or custom, and provide the template), (4) PR process: required reviewers, CI checks that must pass, merge strategy (squash/rebase/merge commit), (5) release process: how to cut a release, tag format (semver), changelog generation, (6) hotfix process: how to patch production without disrupting development, (7) CI/CD trigger rules: which branches trigger which pipelines. Include a visual diagram of the branch lifecycle described in text/ASCII art. Address how to handle long-running feature branches.

Why this prompt works

What carries this is the alignment between branching model (Git Flow / GitHub Flow / Trunk-Based / hybrid), PR rules, and CI triggers. Most generated git workflow docs cover branching but skip the CI side, which is where teams lose most of the time when conventions don't match. The 'justify why it fits this team' constraint forces the model to actually pick one rather than describing all options. The constraint score is 70 because the prompt is light on banning bad patterns, but the structural completeness compensates: by covering hotfixes, releases, and long-running branches explicitly, the doc addresses the situations where loose workflows usually break down.

When to reach for it

You're a new engineering lead inheriting a team without a documented workflow and want one to ratify in a single meeting.
You're moving from a workflow that used to work for 3 people but is breaking down at 12.
You're standardising across multiple repos in an organisation and need a shared baseline.
You're contracting and want to set workflow expectations clearly with the client team upfront.

How to customise it

The team size and product type fields drive the recommendation. A team of 3 working on a SaaS product fits GitHub Flow or trunk-based; a team of 30 with multiple long-running release lines fits Git Flow or a hybrid. Stating the actual pain points in the brief is what gets you a workflow that addresses them rather than a generic best-practice doc. For mobile teams (iOS/Android), add 'address App Store review delays in the release process'; the standard template assumes web release cadence.

What good output looks like

A document with named sections: branching model with justification, naming convention with examples, commit message format, PR process (reviewers, checks, merge strategy), release process with semver and changelog, hotfix flow, CI/CD trigger rules, plus an ASCII diagram of branch lifecycle. Long-running branches addressed with a specific recommendation. Length around 1,500 to 2,500 words.

gitbranching strategyDevOpsCI/CDworkflowChatGPT / Claude