Git Recovery
Interactive recovery from common git mistakes. Safe operations with verification steps.
Quick Start
/git-recovery
Recovery Scenarios
When invoked, present these options to the user:
Option 1: Undo Last Commit (Keep Changes)
Scenario: You committed but want to modify the changes before recommitting.
# Check current state first git log --oneline -3 git status # Undo commit, keep changes staged git reset --soft HEAD~1 # Verify git status # Changes should be staged git log --oneline -1 # Previous commit is now HEAD
Safety: Non-destructive. All changes remain staged.
Option 2: Undo Last Commit (Discard Changes)
Scenario: You committed something completely wrong and want to throw it away.
WARNING: DESTRUCTIVE - Changes will be lost!
# CRITICAL: First, save a backup reference BACKUP_REF=$(git rev-parse HEAD) echo "Backup ref: $BACKUP_REF (save this to recover if needed)" # Show what will be lost git show HEAD --stat # Confirm with user before proceeding # Then execute: git reset --hard HEAD~1 # Verify git log --oneline -3 git status # Should be clean
Recovery: If you made a mistake, run git reset --hard $BACKUP_REF
Option 3: Recover Deleted Branch
Scenario: You deleted a branch and need it back.
# Find the branch's last commit in reflog git reflog | grep -i "branch-name" # Or search all recent activity: git reflog --all | head -30 # Once you find the commit hash (e.g., abc1234): git checkout -b recovered-branch abc1234 # Verify git log --oneline -5 git branch -v | grep recovered
Note: Reflog keeps entries for ~90 days by default.
Option 4: Reset File to Last Commit
Scenario: You modified a file and want to discard local changes.
WARNING: DESTRUCTIVE - Uncommitted changes to file will be lost!
# Show current changes to file git diff path/to/file # Confirm with user before proceeding # Then restore: git checkout HEAD -- path/to/file # Or using newer git restore (Git 2.23+): git restore path/to/file # Verify git status path/to/file # Should show no changes git diff path/to/file # Should be empty
Option 5: Undo a Rebase
Scenario: A rebase went wrong and you want to return to pre-rebase state.
# Find the pre-rebase state git reflog | head -20 # Look for entry like: "rebase (start): checkout main" # The entry BEFORE that is your pre-rebase state # Alternative: ORIG_HEAD is set automatically before rebase git log --oneline ORIG_HEAD -3 # Reset to pre-rebase state git reset --hard ORIG_HEAD # Verify git log --oneline -5 git status
Safety: ORIG_HEAD is overwritten by other operations, use reflog if ORIG_HEAD is stale.
Option 6: Undo a Merge
Scenario: You merged a branch and want to undo it.
# If merge commit exists and NOT pushed: git log --oneline -5 # Find the merge commit # Reset to before merge git reset --hard HEAD~1 # If you need to specify which parent: git reset --hard ORIG_HEAD # Verify git log --oneline -5 git branch -v
WARNING: If already pushed, use git revert -m 1 <merge-commit> instead to create a new commit that undoes the merge.
Option 7: Find Lost Commits (Reflog Deep Dive)
Scenario: You lost commits and need to find them.
# View full reflog with dates
git reflog --date=relative
# Search for specific text in commit messages
git reflog | xargs -I {} git log -1 --format="%h %s" {} 2>/dev/null | grep "search-term"
# Show reflog for specific branch
git reflog show branch-name
# Once found (e.g., abc1234), examine it:
git show abc1234
# Recover by creating a branch or cherry-picking:
git branch recovered-work abc1234
# Or:
git cherry-pick abc1234
Option 8: Unstage Files (Keep Changes)
Scenario: You staged files you didn't mean to stage.
# Unstage specific file git reset HEAD path/to/file # Or using newer git restore (Git 2.23+): git restore --staged path/to/file # Unstage all files git reset HEAD # Verify git status # Files should be unstaged but modified
Safety: Non-destructive. Changes remain in working directory.
Interactive Workflow
When /git-recovery is invoked:
- •
Show current git state:
bashgit status git log --oneline -5
- •
Present recovery options:
codeGit Recovery Options: 1. Undo last commit (keep changes staged) 2. Undo last commit (discard changes) [DESTRUCTIVE] 3. Recover deleted branch 4. Reset file to last commit [DESTRUCTIVE] 5. Undo a rebase 6. Undo a merge 7. Find lost commits (reflog search) 8. Unstage files Which scenario? (1-8):
- •
For destructive operations:
- •Always show what will be lost
- •Provide backup command
- •Require explicit confirmation
- •
After recovery:
- •Run verification commands
- •Show new state
- •Confirm success
Safety Rules
- •NEVER use
--forceon shared branches without explicit user confirmation - •ALWAYS show backup reference before destructive operations
- •ALWAYS verify after each recovery operation
- •Check if changes are pushed before suggesting reset vs revert
Common Gotchas
| Problem | Wrong Approach | Right Approach |
|---|---|---|
| Undo pushed commit | git reset --hard | git revert <commit> |
| Recover deleted branch | Panic | git reflog + checkout |
| Undo rebase on shared branch | git reset | git revert each commit |
| Lost commits after reset | Assume lost | git reflog saves the day |
Related Skills
- •commit: Create commits with validation
- •stacked-prs: Manage PR stacks safely
- •release-management: Handle release branch operations