What this prompt does
This prompt analyses whether your team of [team_size] should keep [current_strategy] or switch between rebase and merge, based on your [workflow_description]. It weighs the pros and cons for your specific workflow, the impact on history readability and blame accuracy, the risks of interactive rebase on shared branches, and produces concrete rules plus a recovery playbook. The output is meant to settle the debate with reasoning rather than preference.
It works because the right answer genuinely depends on branch lifespan and how much history is shared, and the prompt forces those details to the surface. By describing your [workflow_description] — feature branches, review gates, release cadence — you get rules tied to your reality: when to rebase, when to merge, when to squash-merge. It also delivers branch-protection config and a recovery playbook for botched rebases, which is what usually scares teams off rebasing in the first place. A per-PR flowchart turns the policy into something the whole team can follow consistently.
When to use it
- Your team is debating switching from
[current_strategy]and wants a grounded recommendation - Git history has become hard to read and you want a cleaner, defensible policy
- People are nervous about rebasing shared branches and need a safety net
- You want concrete rules for when to rebase, merge, or squash-merge
- You need branch-protection and pull configuration to enforce the chosen approach
- Onboarding new developers and wanting a per-PR flowchart everyone can follow
Example output
You get an analysis document: a pros/cons breakdown of rebase versus merge for your [workflow_description], notes on history and blame impact, a risk assessment for interactive rebase on shared branches, an explicit rule set covering rebase/merge/squash, configuration for git pull strategy and branch protection, a recovery playbook for common mistakes (pushed the wrong thing, conflict mid-rebase), a per-PR flowchart your team can follow, and sample git commands for each scenario.
Pro tips
- Describe
[workflow_description]in detail (branch sources, review gates, release cadence) because branch lifespan drives the recommendation - State
[current_strategy]honestly so the analysis compares against what you actually do, not an idealised baseline - Match the advice to
[team_size]; small teams tolerate looser rules, larger teams need stricter branch protection to prevent shared-branch rebases - Lean on the recovery playbook — knowing how to undo a bad rebase with git reflog is what makes a team comfortable adopting it
- Use the flowchart as the single source of truth for PRs so the policy survives beyond the people who originally set it
- Decide your squash-merge rule deliberately, since squashing keeps history tidy but loses the granular commit trail that blame sometimes needs
- Never rebase a branch others have already pulled from; let the rules in the output encode that boundary explicitly
