What this prompt does
This prompt designs a Git branching strategy tailored to a [team_size]-person team building a [project_type]. It factors in how often you ship ([deploy_frequency]) and how ([deploy_method]), then defines branch naming conventions, a merge-versus-rebase policy per branch type, and protection rules for your main and develop branches. It also builds in a hotfix workflow with rollback steps, a release process with changelogs, and an ASCII diagram of the flow.
The structure works because it ties the strategy to your actual constraints rather than dogma. A team deploying multiple times a day usually belongs on a trunk-based flow with feature flags and tight protection rules, while slower release cadences may justify more long-lived branches. By asking for your [pain_points] directly, the prompt grounds its recommendation in the specific problems you have, like long-lived branches that keep colliding. It also produces an ASCII diagram of the branch flow so the model is easy to communicate, a release process with changelogs, and explicit guidance on how feature flags interact with branches, which is the lever that lets fast-moving teams merge unfinished work safely instead of hiding it in branches that drift further from main every day.
When to use it
- You are onboarding a
[team_size]-person team onto a shared CI/CD workflow. - Long-lived feature branches keep causing painful merge conflicts (
[pain_points]). - Your
[deploy_frequency]has outgrown the branching model you started with. - You need explicit protection rules and a merge-versus-rebase policy the whole team follows.
- You want a documented hotfix-and-rollback workflow before the next production fire.
- You are introducing feature flags and need them to fit cleanly into your branch flow.
Example output
Expect a complete strategy document: branch naming conventions, a per-branch merge/rebase policy, protection rules for main and develop, a hotfix workflow with rollback steps, and a release process that generates changelogs. It includes guidance on how feature flags interact with branches and an ASCII diagram of the overall flow, with the recommendation shaped by your [deploy_frequency] and stated [pain_points].
Pro tips
- State your real
[deploy_frequency]; a team shipping multiple times a day needs a very different model than one releasing monthly. - Be specific in
[pain_points], because the strategy is most useful when it directly attacks the problems you actually have. - Match the recommendation to
[team_size]; heavyweight GitFlow often overwhelms small teams that would thrive on trunk-based development. - If you deploy continuously, lean into the feature-flag guidance so unfinished work can merge safely behind a flag.
- Treat the protection rules as a starting point and tighten them as the team matures, rather than enforcing everything on day one.
- Iterate by describing a recent conflict or botched release and asking it to refine the workflow to prevent that exact situation.
