What this prompt does
This prompt casts the model as an engineer fluent in Git history surgery and asks it to specify a branch cleanup tightly enough to run blind, returning exact, safe commands only. Three placeholders drive it: [commit_count] (how many commits the rebase plan must cover), [target_branch] (what you are merging into and diffing against), and [backup_branch] (the safety branch created before anything is rewritten).
The structure works because interactive rebase is unforgiving, so the prompt front-loads safety and verification. It mandates creating [backup_branch] as step one, then a full git rebase -i plan with pick/squash/fixup/reword for each commit grouped by logical change, a conventional commit message per group, and a step that confirms the diff against [target_branch] is unchanged afterward. That last check is what proves you cleaned history without altering the actual code. Setting [commit_count] correctly keeps the plan aligned with what the editor will actually present, so each instruction maps to a specific commit rather than a guessed position in the list.
When to use it
- You have a feature branch full of "wip" and "fix typo" commits to tidy before merge.
- You want a planned
git rebase -iscript for[commit_count]commits instead of improvising in the editor. - You need conventional commit messages drafted per logical change.
- You want proof the rebase did not change the resulting diff against
[target_branch]. - You expect conflicts mid-rebase and want abort-and-recover steps ready.
- You need the safe force-push guidance (
--force-with-lease) for after the cleanup.
Example output
Expect an ordered, annotated command list. It opens with creating [backup_branch], then lays out the full git rebase -i plan marking each of the [commit_count] commits as pick, squash, fixup, or reword, grouped by logical change, with a suggested conventional commit message (type, scope, subject) per group. It closes with a verification step diffing against [target_branch], mid-rebase conflict handling including abort-and-recover, and a note on force-pushing safely with --force-with-lease. Each line is annotated with what it does and why it is safe.
Pro tips
- Always run the backup step first — cutting
[backup_branch]before touching rebase is what lets you experiment without fear of losing work. - Set
[commit_count]accurately so the rebase plan matches whatgit rebase -iwill actually show you. - Use the verification diff against
[target_branch]every time; a clean history that changed the code is a failed rebase. - Force-push with
--force-with-lease, never plain--force, so you do not clobber a teammate's push you have not pulled. - If conflicts get messy, prefer the abort-and-recover path back to
[backup_branch]over forcing a resolution you are unsure about. - Group commits by logical change before deciding squash vs fixup; fixup drops the message, so reserve it for noise like "fix typo" rather than meaningful work.
- Write the conventional commit subjects to describe the squashed result, not any single original commit, so the history reads cleanly after the rebase.
