Git Workflow Slash Commands
The most-installed slash-command category, bar none. 18 production-tested git commands covering everyday operations, rescue workflows, and advanced patterns (worktrees, submodules, bisect).
Why git commands are the single most-installed slash-command category
Every survey we've run — newsletter, waitlist, and community submissions — agrees on one thing: /commit is the first slash command developers write. Git commands top every ranking because git operations are frequent (many per day), repetitive (same shape every time), and high-value to get right (the difference between a great commit message and a bad one compounds across a team). That's a textbook slash-command pattern.
The 18 commands on this page are the field-tested set that our editorial team uses and that community contributors most often submit variations of. They split into three job families: everyday operations you do dozens of times a week, rescue operations you reach for when things go wrong, and advanced operations for specialized workflows (worktrees, submodules, bisect).
git diff, git log, branch tracking) before acting, so the output reflects what's really in your working tree — not a plausible guess. That's why every command on this page reads git state as its first step.
Anatomy of /commit — the reference implementation
If you're going to write one slash command, write this one. It's short, high-value, and demonstrates the pattern the other 17 follow.
Three things this command does that a naive one wouldn't:
- Reads git state before writing. The
!`git diff --cached --stat`lines fill the context with the actual diff, not just what Claude assumes is staged. - Learns your team's style.
git log --oneline -5shows the last five commits so the new one matches your team's phrasing (all-lowercase? scope prefixes? emoji?). - Refuses to lump concerns. If the diff crosses two unrelated concerns, it asks about splitting. Commit hygiene, not just commit writing.
Rescue commands — the ones you'll thank us for later
Everyday commands are the daily workhorses. The rescue commands are what you'll remember installed at 11pm when a rebase went sideways.
/conflict-resolve— walks you through a merge/rebase conflict, one file at a time, showing both sides and proposing resolutions with reasoning./revert-safe— the counterpart to a bad merge. Inspects the target commit's effect and generates a proper revert (not a force-push, not a reset), with a follow-up commit message./reflog-recover— when you truly can't find a commit, this readsgit reflog, ranks candidate lost commits by recency and message, and offers to check them out to a rescue branch./bisect— scripted bisect flow that runs your test command at each step, so you don't have to remember the six-argumentgit bisectincantation.
Git slash commands vs git hooks — complementary, not competing
Both shape git behavior in Claude Code, and they cover different jobs:
- Slash commands for the authoring side — write a commit, open a PR, resolve a conflict. You reach for these.
- Git hooks for the enforcement side — block commits to main, auto-branch per session, prevent force-push. These fire whether you asked or not.
A mature setup runs /commit for daily commit work, with a prevent-commit-main hook that blocks Claude if it ever tries to commit directly to main and a secrets-scan-on-write hook that stops secret leaks pre-commit. Three layers, one clean workflow.
All 18 git commands, grouped by job family
Every command reads real git state before acting. Grouped into everyday operations (commits, branches, PRs), rescue workflows (conflicts, reverts, reflog), and advanced patterns (bisect, worktrees, submodules).
Which git commands should I install?
Install these in order — each unlocks the next tier of workflow value.
Related sub-categories in Slash Commands
Git commands pair naturally with deployment, code review, testing, and documentation — the day-to-day authoring commands most teams install together.
🐛 Hit an error while using these?
Our sister site AI Error Hub covers Claude Code errors, MCP connection failures, and stack traces — cross-referenced with everything on this site.
Frequently asked questions
The questions developers ask most about git workflows.
/commit. Every survey we've run puts it first.
Git commits are the most frequent repetitive-shape operation in every project, so codifying them into a slash command pays back its authoring cost within a day. If you install one command from this whole site, install /commit first.
It reads the last five commits from git log --oneline -5 as part of its context. The rule "match the team's existing commit style from the recent-commits list" is embedded in the command body.
If your team uses lowercase, scope prefixes, or a specific emoji convention, the new commit follows. Style is learned per-project, not baked in.
Conditionally, yes. The reference implementation stages unstaged files if nothing is currently staged — but only files that look intentional.
It explicitly skips:
- Lockfiles (
package-lock.json,poetry.lock) - Generated artefacts (
dist/,build/) - Env files (
.env,.env.local)
That heuristic catches 95% of cases; for the rest, stage manually first.
It generates the title and description for you from the actual branch diff, following the team's PR template if one exists.
That saves the two minutes of writing "what does this PR do?" every time and produces PR descriptions with a consistent shape.
Requires a GitHub or GitLab MCP for the actual API call; without one, it just prepares the content and shows the gh pr create command.
Narrow git subsets. For /commit:
Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git log:*)
Do not allow general Bash — a commit command should not be able to run rm or curl. This is the biggest single safety mechanism for team-shared git commands.
Not by default. Even /pr-create should stop short of pushing without confirmation — a slash command that pushes without a beat is one Claude misinterpretation away from a bad state.
If you do allow push, pair it with prevent-commit-main and approve-git-force-push hooks so any push to main or force-push is caught at the tool layer regardless.
Yes for most everyday conflicts — the 90% case where both sides made semantically compatible changes and the merge just needs a human eye.
It's much less useful for genuinely divergent changes (both sides restructured the same function differently). For that, it will show both versions and ask for guidance rather than guessing.
Treat it as a walk-through assistant, not an autonomous resolver.
Yes if you provide a test command that returns non-zero on the bad state.
The command sets up git bisect start, runs bisect good/bisect bad based on the test at each step, and reports the offending commit.
Works well when you have a fast reproducer. For slow tests, expect the bisect to take a while — that's a git property, not a command limitation.
Slash commands for individual git operations — that's what they were built for.
Reserve subagents for larger workflows:
- "Audit the last 100 commits for merges that should have been rebases."
- "Reconstruct a lost feature from three parallel branches."
Rule of thumb: if the job is one git operation, use a command; if it needs to explore history and make multi-step decisions, use a subagent.
Three commands cover 80% of daily git:
/commit/branch/pr-create
Add /conflict-resolve for peace of mind (you'll thank yourself at 11pm the day you actually need it).
Pair with the prevent-commit-main hook for enforcement. That five-piece set is the default recommendation for every team we onboard.