Git undo

Skill KhaledSaeed18/dotclaude/skills/version-control/git-undo

Reusable Claude Code extension registry. skills, subagents, slash commands, and hooks for engineering, git, testing, and security workflows. Distributed as a shadcn GitHub registry and as installable plugins.

Install

npx -y skills add KhaledSaeed18/dotclaude --skill git-undo

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Recover safely from Git mistakes such as discard, unstage, amend, reset, revert, restore lost commits via reflog, recover deleted branches, and fix bad rebases. Chooses the least-destructive fix and protects against data loss. Use when something in Git went wrong and needs undoing.

SKILL.md

4.9 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Undo the mistake with the least-destructive tool that fits, after establishing two facts that change everything: has the work been committed, and has it been pushed/shared. Get those wrong and you either lose work or rewrite history other people depend on.

Hard rules: never break these

Diagnose before acting. Establish: committed or not? pushed or not? on a shared branch? Run git status, git log --oneline -10, and git reflog -20 first. The fix depends entirely on the answers.
Never rewrite published history casually. For anything already pushed to a shared branch, undo forward with git revert; do not reset/rebase/commit --amend and force-push unless the user explicitly owns the consequences and coordinates with collaborators.
Take a safety net before any destructive op. Before reset --hard, a force-push, or a history rewrite, snapshot the current tip: git branch backup/<desc> or git tag backup/<desc>. Reflog usually saves you, but a branch is free insurance.
--hard and clean destroy uncommitted work irrecoverably. Reflog only recovers committed states. Spell out exactly what will be lost and confirm before running them.
Confirm before any destructive or shared-history command: reset --hard, clean -fd, push --force*, history rewrites. Prefer push --force-with-lease over --force when a rewrite is genuinely required.

Step 1: Diagnose

git status: staged vs unstaged vs untracked; any operation in progress.
git log --oneline --graph -15: recent commits and branch shape.
git reflog -25: the time machine, every position HEAD has held, even "lost" ones. This is how you recover almost anything committed.
Determine shared or local: has the affected commit/branch been pushed? git status (ahead/behind), git branch -r --contains <sha>.

Step 2: Pick the fix

Match the situation to the safest tool:

Uncommitted work

Discard changes in a file → git restore <file> (was git checkout -- <file>).
Unstage but keep changes → git restore --staged <file> (was git reset HEAD <file>).
Set aside without losing → git stash push -m "<note>"; bring back with git stash pop.
Remove untracked files → git clean -nd (dry run first!), then git clean -fd once confirmed.

The last commit (not yet pushed)

Wrong message → git commit --amend.
Forgot a file → stage it, then git commit --amend --no-edit.
Undo the commit, keep changes staged → git reset --soft HEAD~1.
Undo the commit, keep changes unstaged → git reset --mixed HEAD~1 (default).
Undo the commit and discard changes → git reset --hard HEAD~1 (destructive; safety net first).

Already pushed / shared branch

Undo a commit safely → git revert <sha> (creates an inverse commit; history stays intact). Revert a merge with -m 1.

Wrong-branch / structural mistakes

Committed to the wrong branch → create the right branch from here (git branch feature), then git reset --hard origin/<wrong-branch> on the original (safety net first); or git cherry-pick the commits onto the right branch and drop them from the wrong one.
Need an old version of one file → git restore --source=<sha> -- <file>.

Recovering things that look lost

Hard reset / branch deletion / bad amend → find the old SHA in git reflog, then git branch recovered <sha> or git reset --hard <sha>.
Botched rebase/merge → git reset --hard ORIG_HEAD returns to the pre-operation tip.
Deleted branch with no reflog entry → git fsck --lost-found lists dangling commits.
Dropped a stash → git fsck --no-reflog | grep commit, or recover from git reflog stash.

Step 3: Safety net (before anything destructive)

Snapshot the current tip so the operation is reversible regardless of outcome:

git branch backup/before-undo        # or: git tag backup/before-undo

Note the current HEAD SHA too. This costs nothing and turns "irreversible" into "recoverable."

Step 4: Execute (with confirmation)

State plainly: what command runs, what it changes, and what (if anything) is lost forever.
For destructive or shared-history operations, get an explicit yes. For force-pushes, use --force-with-lease and confirm no one else's work is being overwritten.
Run it.

Step 5: Verify

git status and git log --oneline -5 to confirm the tree and history are what you intended.
Confirm recovered work is present (file contents, expected commits).
Note the safety branch/tag you created; remove it once the user confirms the recovery is good.

Gives 0 of the 12 instructions most pr commit review skills give in ~1.1k tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-06

use conventional commits formatin 123 of 888, across 110 files
keep subject line under 72 charactersin 60 of 888, across 46 files
delete branches after mergein 50 of 888, across 37 files
use imperative mood in subject linein 50 of 888, across 41 files
use imperative mood in commit messagesin 45 of 888
generate a conventional commit messagein 42 of 888
make atomic commitsin 37 of 888, across 25 files
run tests before committingin 36 of 888, across 24 files
run project test suite to verify clean baselinein 35 of 888, across 7 files
run detected project setup commandsin 34 of 888, across 6 files
wrap commit body at 72 charactersin 32 of 888, across 25 files
split unrelated changes into separate commitsin 32 of 888, across 27 files

Said here and by no other author read

diagnose state before acting
choose least-destructive tool
state what is lost before running
verify history after operation
clean up backup branch after recovery

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.