Documentation
Everyday Git: Practical Workflows & Commands
Undoing Changes

Undoing Changes

Undoing Changes: Navigating Git’s Time-Travel Mechanisms

Git provides multiple mechanisms for undoing changes, each operating at different levels of the repository structure—working tree, staging area, and commit history. Understanding when to use each operation prevents data loss and maintains repository integrity.

Understanding reset operations? Our Understanding HEAD guide explains what HEAD is and how commands like git reset modify it.

The Three States of Git Content

Before exploring undo operations, recognize Git’s three-layer architecture:

  1. Working Directory: Your actual files on disk
  2. Staging Area (Index): Snapshot of what goes into next commit
  3. Repository (Commit History): Permanent record of committed snapshots

Different undo operations target different layers, requiring distinct Git commands.

Discarding Working Directory Changes

Restoring Modified Files

When you’ve edited files but haven’t staged changes, use git restore to discard modifications:

# Discard changes to specific file
git restore src/auth.py
# File reverts to last committed state

# Discard changes to multiple files
git restore src/auth.py tests/test_auth.py

# Discard all modified files in repository
git restore .

# Discard changes in specific directory
git restore src/

Note: The git restore command requires Git 2.23+ (released August 2019). On older versions, use git checkout -- <file> instead.

Effect:

  • Working directory: File contents revert to HEAD commit
  • Staging area: Unchanged
  • Repository: Unchanged

Warning: This operation is destructive—modifications are permanently lost. Use git stash if you might need changes later:

# Save changes for possible restoration
git stash push -m "WIP: Authentication refactor"

# Later, if needed:
git stash pop  # Restore changes
# Or: git stash drop  # Discard permanently

Restoring Deleted Files

If you deleted a file in your working tree:

# File accidentally deleted
rm important-file.py

# Check status
git status
# deleted:    important-file.py

# Restore from last commit
git restore important-file.py
# File reappears with committed contents

Interactive Restoration

For selective restoration within files:

# Restore specific changes interactively
git restore -p file.py
# Git prompts for each change hunk:
# Discard this hunk [y,n,q,a,d,/,e,?]?

# y: discard this hunk
# n: keep this hunk
# q: quit (keep remaining hunks)
# a: discard all remaining hunks
# e: manually edit hunk

Use Case: You made multiple unrelated changes to a file but want to keep some modifications while discarding others.

Unstaging Changes

Removing Files from Staging Area

After staging changes with git add, but before committing, you can unstage:

# Stage file
git add feature.py

# Change your mind, unstage
git restore --staged feature.py

# Check status
git status
# Changes not staged for commit:
#   modified:   feature.py

# File remains modified in working tree
# Only staging area affected

Effect:

  • Working directory: Unchanged (modifications preserved)
  • Staging area: File removed from next commit
  • Repository: Unchanged

Unstaging Multiple Files 

# Unstage all staged files
git restore --staged .

# Unstage specific files
git restore --staged file1.py file2.py

# Unstage files matching pattern
git restore --staged '*.log'

Interactive Unstaging 

# Unstage specific changes within file
git restore --staged -p feature.py

# Selectively unstage hunks
# Useful after `git add -p` when you staged too much

Modifying the Last Commit

Amending Commit Message

To change the most recent commit’s message:

# Edit last commit message
git commit --amend
# Opens editor with current message
# Edit message, save, and close

# Quick amend without editor
git commit --amend -m "Corrected commit message"

Technical Effect: Creates new commit object with:

  • Same tree (file contents)
  • Same parent
  • Different message → Different SHA-1 hash

Original commit becomes unreferenced (eventually garbage collected).

Adding Forgotten Files to Last Commit

Forgot to include a file in your commit?

# Make commit
git commit -m "Add user authentication"

# Realize you forgot tests
git add tests/test_auth.py

# Add to previous commit (no new commit created)
git commit --amend --no-edit
# --no-edit: Keep existing commit message

Result: Last commit now includes both original files and test_auth.py.

Changing Commit Author

Fix incorrect author information:

# Amend author metadata
git commit --amend --author="Jane Smith <[email protected]>"

# Amend only author name (keep email)
git commit --amend --author="Jane Smith"

Use Case: Committed from wrong machine, used incorrect Git configuration, or need to credit different contributor.

Comprehensive Amend: Content and Message 

# Modify files
vim src/auth.py
vim tests/test_auth.py

# Stage changes
git add src/auth.py tests/test_auth.py

# Amend commit with new content and message
git commit --amend -m "Add user authentication with comprehensive tests"

Critical Warning: Only amend commits that haven’t been pushed. Amending published commits requires force-push, rewriting history for everyone.

Undoing Commits: Reset Operations

Git’s reset command moves branch pointers backward, effectively “uncommitting” changes. Three modes control what happens to your staging area and working directory.

Reset Mode 1: --soft (Keep Everything Staged)

Moves branch pointer backward while preserving all changes in staging area:

# Undo last commit, keep changes staged
git reset --soft HEAD~1

# Check status
git status
# Changes to be committed:
#   modified:   file1.py
#   modified:   file2.py

Effect:

  • Working directory: Unchanged (all modifications preserved)
  • Staging area: All changes from undone commit(s) remain staged
  • Repository: Branch pointer moved backward

Use Cases:

  • Split one commit into multiple commits
  • Improve commit message with better organization
  • Re-stage changes differently before committing

Example Workflow:

# Made large unfocused commit
git reset --soft HEAD~1

# Now reorganize into logical commits
git reset  # Unstage everything
git add auth.py
git commit -m "Implement authentication logic"

git add tests/
git commit -m "Add authentication tests"

git add docs/
git commit -m "Document authentication API"

Reset Mode 2: --mixed (Unstage Everything)

Default reset mode. Moves branch pointer and clears staging area, but preserves working tree:

# Undo last commit, unstage changes
git reset HEAD~1
# Equivalent to: git reset --mixed HEAD~1

# Check status
git status
# Changes not staged for commit:
#   modified:   file1.py
#   modified:   file2.py

Effect:

  • Working directory: Unchanged (modifications preserved)
  • Staging area: Cleared (changes unstaged)
  • Repository: Branch pointer moved backward

Use Cases:

  • Restructure which changes go into which commits
  • Made wrong commits, want to re-stage differently
  • Split combined changes into separate logical commits

Example Workflow:

# Last 2 commits should be reorganized
git reset HEAD~2

# All changes from both commits now unstaged
git add feature_a.py
git commit -m "Implement feature A"

git add feature_b.py
git commit -m "Implement feature B"

git add bug_fix.py
git commit -m "Fix related bug"

Reset Mode 3: --hard (Discard Everything)

DESTRUCTIVE: Moves branch pointer and discards all changes in staging area and working tree:

# Undo commits and destroy all changes
git reset --hard HEAD~1

# Check status
git status
# nothing to commit, working tree clean

Effect:

  • Working directory: Reverted to specified commit (modifications LOST)
  • Staging area: Cleared
  • Repository: Branch pointer moved backward

Critical Warnings:

  1. Uncommitted changes are permanently destroyed
  2. Cannot be recovered unless stashed first
  3. Use with extreme caution

Safe Alternative:

# Preserve changes before hard reset
git stash push -m "Backup before reset"

# Perform reset
git reset --hard HEAD~3

# If you regret it, recover changes
git stash pop

Reset Summary Table

ModeWorking DirectoryStaging AreaRepository (HEAD)
--softUnchangedUnchanged (staged)Moved backward
--mixed (default)UnchangedClearedMoved backward
--hardRevertedClearedMoved backward

Recovering from Accidental Reset

Git’s reflog tracks HEAD movements, enabling recovery from mistaken resets:

# Accidentally reset too far
git reset --hard HEAD~5
# Oh no! Needed those commits

# View reflog to find lost commit
git reflog
# abc123 HEAD@{0}: reset: moving to HEAD~5
# def456 HEAD@{1}: commit: Important work (LOST)
# ghi789 HEAD@{2}: commit: More important work

# Restore to state before reset
git reset --hard def456
# All "lost" commits restored

Reflog Limitations:

  • Entries expire after 90 days (default)
  • Only tracks local operations (not available after cloning)
  • Doesn’t help with uncommitted changes lost to --hard reset

💡 Useful Aliases

git config --global alias.unstage 'reset HEAD --'
git config --global alias.undo 'reset --soft HEAD^'

These aliases make common undo operations more intuitive. Use git unstage to remove files from staging area, and git undo to undo the last commit while keeping changes staged.

Creating Inverse Commits: Git Revert

Unlike reset which rewrites history, revert creates new commits that undo previous commits—ideal for fixing mistakes in published history.

Basic Revert Operation 

# Undo commit D by creating inverse commit D'
git revert abc123

# Git creates new commit that reverses abc123's changes
# Editor opens for revert commit message

Conceptual Model:

Before: A - B - C - D (faulty commit)
After:  A - B - C - D - D' (inverse of D)

Key Characteristics:

  • Non-destructive: Original commits remain in history
  • Safe for published history: Doesn’t require force-push
  • Auditable: Clear record of what was undone and why

Reverting Multiple Commits 

# Revert last 3 commits (creates 3 revert commits)
git revert HEAD~2..HEAD
# Or: git revert HEAD HEAD~1 HEAD~2

# Revert range without creating commits yet
git revert --no-commit HEAD~2..HEAD
# Stages all inverse changes
# Create single revert commit:
git commit -m "Revert authentication changes from commits D, E, F"

Handling Revert Conflicts

If reverted commits conflict with subsequent changes, manual resolution required:

# Attempt revert
git revert abc123
# Auto-merging auth.py
# CONFLICT (content): Merge conflict in auth.py

# Resolve conflicts
vim auth.py
# Fix conflicts manually

# Complete revert
git add auth.py
git revert --continue

# Or abandon revert
git revert --abort

Reverting Merge Commits

Merge commits have multiple parents, requiring explicit parent specification:

# Revert merge commit, keeping main branch history
git revert -m 1 abc123
# -m 1: Keep changes from first parent (usually main)
# -m 2: Keep changes from second parent (merged branch)

# Example scenario:
# Merged feature branch, discovered critical bug
git log --oneline
# abc123 Merge branch 'feature-auth' (REVERT THIS)
# def456 (main) Previous work

git revert -m 1 abc123
# Creates commit undoing all feature-auth changes

Critical Note: Reverting a merge prevents future merges of that branch without additional work. See advanced rebase documentation for details.

Comparison: Reset vs. Revert vs. Checkout

OperationHistoryUse CaseSafety
git resetRewritesUnpublished commitsDestructive (esp. --hard)
git revertPreservesPublished commitsSafe
git checkout <commit>UnchangedTemporary explorationSafe (detached HEAD)

Decision Flowchart:

  1. Commit published?
    • No → Use reset
    • Yes → Use revert
  2. Just exploring history? → Use checkout
  3. Need to modify working tree? → Use restore

Real-World Undo Scenarios

Scenario 1: Fixing Typos in Recent Commit 

# Committed with typo in message
git commit -m "Add usre authentication"  # Oops!

# Fix typo (before pushing)
git commit --amend -m "Add user authentication"

Scenario 2: Added Wrong Files 

# Accidentally staged secrets
git add config.py secrets.yaml

# Unstage secrets before committing
git restore --staged secrets.yaml

# Commit only safe files
git commit -m "Update configuration"

Scenario 3: Committed to Wrong Branch 

# On main, made commit that should be on feature branch
git branch feature-auth  # Create branch at current position
git reset --hard HEAD~1  # Move main back
git checkout feature-auth  # Switch to correct branch
# Commit now only on feature-auth

Scenario 4: Deployed Broken Code 

# Deployed commit abc123, discovered critical bug
# Can't rewrite history (already deployed)

# Create inverse commit
git revert abc123
git push origin main

# Deploy revert commit to production

Scenario 5: Multiple Bad Commits 

# Last 5 commits are wrong, not published yet
git reset --soft HEAD~5

# All changes from 5 commits now staged
# Reorganize properly
git reset  # Unstage
# ... stage and commit properly ...

Advanced Undo Operations

Restoring Files from Specific Commits 

# Restore file from different commit
git restore --source=abc123 src/auth.py
# auth.py now has contents from commit abc123

# Restore file from 5 commits ago
git restore --source=HEAD~5 config.py

# Restore and stage
git restore --source=abc123 --staged --worktree auth.py

Undoing Staging Area Changes 

# Staged wrong changes with `git add -p`
git restore --staged -p file.py
# Interactively unstage hunks

Partial File Revert 

# Undo specific lines changed in commit
git show abc123:src/auth.py > temp.py
# Edit temp.py to keep wanted changes
mv temp.py src/auth.py
git add src/auth.py
git commit -m "Partially revert abc123 changes in auth.py"

Cherry-Pick in Reverse

If you need changes from reverted commit later:

# Original: A - B - C - D
# Reverted: A - B - C - D - D' (D' undoes D)

# Later, want D's changes back
git revert D'
# Creates D'' which undoes the undo (re-applies D)

# Or: Cherry-pick original commit
git cherry-pick D

Undo Operation Safety Checklist

Before performing destructive operations:

# 1. Check repository status
git status

# 2. View what will be affected
git diff
git diff --staged

# 3. Create safety checkpoint
git stash push -m "Safety backup before reset"
# Or: git branch backup-$(date +%Y%m%d-%H%M%S)

# 4. Verify you're on correct branch
git branch

# 5. Check if commits are published
git log origin/main..HEAD  # Unpublished commits

Summary: Choosing the Right Undo Operation

Core Principles:

  1. Working directory changes: Use git restore <file>
  2. Unstaging: Use git restore --staged <file>
  3. Last commit modification: Use git commit --amend
  4. Unpublished commits: Use git reset --soft|--mixed|--hard
  5. Published commits: Use git revert
  6. Exploration only: Use git checkout <commit>

Safety Hierarchy (safest to most dangerous):

  1. git restore --staged (only affects staging)
  2. git revert (creates new commits)
  3. git reset --soft (keeps all changes)
  4. git reset --mixed (keeps working tree)
  5. git commit --amend (rewrites last commit)
  6. git reset --hard (destroys uncommitted work)

Golden Rules:

  • Never rewrite published history without team coordination
  • Always backup before destructive operations (git stash or create branch)
  • Use --force-with-lease instead of --force when force-push necessary
  • Check reflog when in doubt (git reflog shows recent HEAD movements)

Integration with Workflow: Undo operations aren’t signs of failure—they’re essential tools for maintaining clean, logical commit history. Master them to confidently experiment, refactor, and organize commits into coherent narratives.

Next Step: Explore Interactive Rebase for sophisticated history rewriting capabilities.

Viewing Changes and Repository HistoryStashing - Temporary Work Preservation