The Git Undo Toolkit – Part 3 – How to Undo Committed Changes in Git?

So far we have covered how to undo your mistakes in git working directory and staging area. In this blog post, we are going to learn how to undo committed changes in git. Say you have committed some changes and then realized that you made a mistake and now you want to fix that mistake. In particular the following scenarios are quite common:

• You just added a commit message only to realize there is a typo in the commit message.
• You realize that you forgot to include an important file in that last commit.
• You pushed a feature branch to the remote, only to discover it breaks everything for your teammates.
• You did lots of commits during testing and now before merging to main wants to clean your commit history.

These are very common scenarios in a regular git workflow. Once a change is committed, especially if it is pushed to a remote repository, the “undo” process becomes more complex but do not worry as git also has different commands in it’s arsenal to deal with mistakes in git commit.

In this comprehensive guide, we will guide you step by step on how to undo or modify commits whether they are still local to your machine or have already been shared with the remote repository.

Undoing Changes in Your Local Repository (Before Pushing)

These scenarios deal with commits that have not yet been pushed to a shared remote repository. These operations are generally safer as you are only affecting your own local history.

Scenario 1: How to Change the Message of Your Last Commit?

A classic mistake. You just committed, and you want to correct a typo or change the commit message. The changes in the commit itself are correct.

Question: How do I edit the commit message of my most recent commit?

Answer: Use git commit --amend.

Code:

# 1. Make a commit with a typo
git commit -m "Fix typoo in documentation"

# 2. Amend the commit message
git commit --amend -m "Fix typo in documentation"

# 3. Check log
git log -1
# The message will now be updated.

Explanation: The git commit --amend command allows you to change the last commit. When used with the -m flag and a new message, it replaces the previous commit’s message. If you run git commit --amend without -m option, Git will open your default text editor, allowing you to edit the existing message.

Notes/Warnings:

• Rewrites History: While simple, git commit --amend actually rewrites the last commit. It do not create a new commit; it replaces the existing one with a new commit ID.
• Do not Amend Pushed Commits: Never amend a commit that has already been pushed to a shared remote repository. Doing so will cause divergence with your team members git history and lead to problems when they try to pull or push. (We will cover how to handle pushed commits later).

Scenario 2: How to Add Forgotten Changes to Your Last Commit?

You just committed, then immediately realized that you forgot to stage and commit a small change or an entire file that should have been part of that last commit.

Question: How do I add a forgotten changes to my most recent commit?

Answer: Stage the forgotten changes (git add), then use git commit --amend.

Example Code:

# 1. Make some changes, commit them, but forget one file
echo "initial content" > file1.txt
git add file1.txt
git commit -m "Add file1"

# 2. Realize you forgot to add file2.txt
echo "forgotten content" > file2.txt
git add file2.txt

# 3. Amend the previous commit to include file2.txt
git commit --amend --no-edit # Use --no-edit to keep the old message

# If you also want to edit the message, just use:
# git commit --amend
# This will open your editor.

# 4. Check log
git log -1 # See the commit message and now file2.txt is part of it.

Explanation: This leverages the git commit --amend command again. By staging the new changes before running git commit --amend, Git adds those staged changes into the new, amended commit, effectively replacing the old one. --no-edit is useful if you want to keep the exact same commit message.

Notes/Warnings:

• Rewrites History: Like simple amending, this rewrites the last commit’s ID.
• Do not Amend Pushed Commits: Importantly, do not use this on commits that have already been pushed to a shared remote unless you know what you are doing.

Scenario 3: How to Undo the Last Commit, But Keep the Changes in Your Working Directory and Staging Area?

You have made a commit, but you have decided it was premature. Now you want to “un-commit” it, leaving the changes exactly where they were before the commit (staged and ready to be re-committed, or modified further).

Question: How do I undo the last commit while preserving its changes in my staging area?

Answer: Use git reset --soft HEAD~1.

Example Code:

# 1. Make some changes and commit
echo "feature A" > feature.txt
git add feature.txt
git commit -m "Implement feature A"

# 2. Decide to undo the commit, but keep changes staged
git reset --soft HEAD~1

# 3. Check status
git status
# You will see feature.txt is now staged (ready to be committed again).

Explanation:

• git reset: This command resets the HEAD pointer to a specified commit.
• --soft: This is the key option. It tells Git to move the HEAD pointer (and your current branch) to the specified commit (HEAD~1 means one commit before HEAD) but leaves your staging area and working directory exactly as they were. All the changes from the undone commit are now in your staging area.
• HEAD~1: Refers to the commit immediately before the current HEAD commit.

Notes/Warnings:

• Rewrites History: This rewrites your local branch’s history by moving the branch pointer. The original commit still exists in the reflog for a period if you need to recover it.
• Local Only: Safe to use on local branches that have not been pushed.

Scenario 4: How to Undo the Last Commit, and Move Its Changes Back to Your Working Directory (Unstaged)?

This is the default git reset behavior. You want to un-commit the last commit, and you want its changes to appear as unstaged modifications in your working directory, as if you had just started working on them.

Question: How do I undo the last commit and move its changes back to my working directory (unstaged)?

Answer: Use git reset HEAD~1 (or git reset --mixed HEAD~1).

Example Code:

# 1. Make some changes and commit
echo "bug fix" > bug.txt
git add bug.txt
git commit -m "Fix critical bug"

# 2. Decide to undo the commit, changes unstaged
git reset HEAD~1

# 3. Check status
git status
# You'll see bug.txt is now modified (unstaged).

Explanation:

• --mixed (default): This option (without --soft or --hard options) moves the HEAD pointer and current branch, resets the staging area to match the target commit (HEAD~1), but leaves your working directory intact. This means all changes from the undone commit are now in your working directory as unstaged modifications.

Notes/Warnings:

• Rewrites History: This will rewrites your local branch’s history.
• Local Only: Safe to use on local branches that have not been pushed. Care should be taken if already pushed to remote repository.

Scenario 5: How to Undo the Last Commit and Completely Discard All Its Changes?

This is the most aggressive form of git reset. You have committed, but then you realize the entire commit was a mistake, and you want to completely remove the commit along with all the changes, reverting your project to the state before that commit.

Question: How do I completely discard the last commit and all its associated changes?

Answer: Use git reset --hard HEAD~1.

Example Code:

# 1. Make some very experimental (and bad) changes, then commit
echo "experimental feature" > new_feature.txt
git add new_feature.txt
git commit -m "Add bad experimental feature"

# 2. Realize it is a disaster and want to nuke it all
git reset --hard HEAD~1

# 3. Check status and files
git status
# new_feature.txt will be gone, and your working directory is clean.

Explanation:

• --hard: This option moves the HEAD pointer and current branch, resets the staging area, AND overwrites the working directory to match the state of the target commit (HEAD~1). All changes introduced by the undone commit are permanently deleted from your working directory and staging area.

Notes/Warnings:

• EXTREMELY DANGEROUS – POTENTIAL DATA LOSS! This command will remove any changes introduced by the specified commit (or commits) in your working directory. Use with extreme caution and only when you are 100% certain you want to discard those changes.
• Local Only: Safe only on local branches that have not been pushed.
• git reflog is your last resort: If you accidentally run git reset --hard, your changes are not immediately gone from Git’s internal database. git reflog might help you find the previous commit ID to recover (covered in a later part of this series).

Scenario 6: How to Undo a Specific Commit That Is Not the Most Recent One (But Has Not Been Pushed Yet)?

You want to remove a commit from your history that is a few commits back. This effectively rewrites history. This is suitable if the changes have not been shared.

Question: How do I remove a specific commit from my local history if it is not the last commit?

Answer: Use git rebase -i (interactive rebase) to “drop” the commit.

Example Code:

# Assume you have commits: A -- B -- C -- D (HEAD)
# You want to remove commit B.

# 1. Start an interactive rebase from the commit *before* the one you want to remove.
# Get hash of commit A (or just HEAD~3 if D is HEAD)
# Example: If B is HEAD~2, then you start from HEAD~3
git rebase -i HEAD~3 # Or git rebase -i <hash-of-commit-A>

This will open an editor (like Vim) showing your recent commits:

pick <hash-B> Commit B message
pick <hash-C> Commit C message
pick <hash-D> Commit D message

# Rebase <hash-A>..<hash-D> onto <hash-A>
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# d, drop <commit> = discard commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit and reset HEAD to it (use with 'label' and 'reset')
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here, that commit will be dropped from the series.
# ...

Change pick to drop for the commit you want to remove:

pick <hash-A> Commit A message
drop <hash-B> Commit B message  # Change 'pick' to 'drop'
pick <hash-C> Commit C message
pick <hash-D> Commit D message

Save and close the editor. Git will then rewrite history, omitting commit B.

Explanation: git rebase -i allows you to interactively rewrite history. By specifying HEAD~N, you tell Git to show you the last N commits. Inside the editor, changing pick to drop for a specific commit instructs Git to rebuild the history without that commit.

Notes/Warnings:

• Rewrites History! This is a powerful command that changes the commit IDs of subsequent commits.
• Local Only! ABSOLUTELY NEVER use this on commits that have already been pushed to a shared remote repository. This will cause severe problems for anyone who has pulled your old history.
• Use with Caution: If you are not comfortable with interactive rebase, practice on a temporary branch first.

Scenario 7: How to Move a Commit to the Correct Branch (Local Only)?

You made a commit on main (or develop) when it should have been on your feature branch, and you have not pushed it yet.

Question: How do I move a commit from the wrong branch to the correct one before pushing?

Answer: Use git reset --hard to move the branch pointer, then git cherry-pick the commit onto the correct branch.

Example Code:

# Assume you are on 'main' and accidentally committed 'feat: new login' here.
# Log: A -- B (feat: new login) -- C (HEAD, main)

# 1. Find the commit hash of the commit you want to move (commit B)
git log --oneline
# Example: d1e2f3g feat: new login

# 2. Reset the incorrect branch (main) to the commit *before* the accidental one (commit A)
git reset --hard HEAD~1
# Or git reset --hard <hash-of-commit-A>

# 3. Switch to the correct branch
git checkout feature-branch

# 4. Cherry-pick the commit you want to move onto this branch
git cherry-pick d1e2f3g # Use the actual hash you found in step 1

# 5. (Optional) Delete the now-empty commit from 'main' (already done by --hard) and verify
git status
git log --oneline

Explanation:

• git reset --hard HEAD~1: Moves the main branch pointer back one commit, effectively “removing” the accidental commit from main‘s history locally.
• git checkout feature-branch: Switches to the target branch.
• git cherry-pick <commit-hash>: Takes a specific commit and applies its changes as a new commit onto the current branch. This preserves the original commit but adds a new one.

Notes/Warnings:

• Local Only: This is suitable only if the incorrect commit has not been pushed. If it has, you will need to use git revert or coordinate a force push (see later sections).
• New Commit ID: cherry-pick creates a new commit, so the original commit ID will differ from the new one.

Scenario 8: How to Split a Single Large Commit into Multiple Smaller Commits?

You have made a commit that contains too many unrelated changes, and you want to break it down for cleaner history before pushing.

Question: How do I break a single large commit into multiple smaller, more focused commits?

Answer: Use git reset --soft to undo the commit, then stage and commit changes selectively.

Example Code:

# 1. Assume you have a large commit "Add feature X and fix bug Y"
# Log: A -- B (Add feature X and fix bug Y) (HEAD)

# 2. Soft reset to the commit *before* the large one
git reset --soft HEAD~1

# 3. Now, all changes from commit B are in your staging area (and working directory).
# Stage only the 'feature X' changes and commit.
git add <files-for-feature-X>
git commit -m "Add feature X"

# 4. Stage only the 'bug Y' changes and commit.
git add <files-for-bug-Y>
git commit -m "Fix bug Y"

# 5. Check log
git log --oneline
# Log: A -- (new)B' -- (new)C'

Explanation: git reset --soft HEAD~1 puts all the changes from the original large commit back into your staging area. From there, you can use git add -p (for interactive staging of parts of files) or just git add <specific-files> to create new, smaller, more focused commits.

Notes/Warnings:

• Rewrites History: This process rewrites the history by replacing one commit with multiple new ones.
• Local Only: Only perform this on local commits that have not been pushed.

Scenario 9: How to Combine (Squash) Multiple Small Commits into a Single, Cleaner Commit?

You have a series of “fix,” “typo,” or “WIP” commits, and you want to combine them into one meaningful commit before pushing.

Question: How do I combine several consecutive commits into a single commit?

Answer: Use git rebase -i (interactive rebase) to “squash” or “fixup” commits.

Example Code:

# Assume commits: A -- B (WIP) -- C (fix typo) -- D (add feature) (HEAD)
# You want to squash B, C, D into one commit starting from A.

# 1. Start an interactive rebase from the commit *before* the first commit you want to squash.
git rebase -i HEAD~3 # If D is HEAD, C is HEAD~1, B is HEAD~2

# Editor opens:
# pick <hash-B> WIP
# pick <hash-C> fix typo
# pick <hash-D> add feature

Change pick to squash (or s) for commits you want to merge into the previous one. Change pick to f (fixup) if you want to discard the commit message of the squashed commit.

pick <hash-B> WIP
squash <hash-C> fix typo
squash <hash-D> add feature

Save and close the editor. Git will combine the commits. If you used squash, another editor will open allowing you to combine/edit the commit messages into a single new message. If you used fixup, the messages will be discarded, and only the “picked” commit’s message will remain.

Explanation: git rebase -i is the tool for git history manipulation. squash combines the current commit with the one above it in the list (the one picked), allowing you to merge their messages. fixup does the same but discards the squashed commit’s message.

Notes/Warnings:

• Rewrites History! This creates entirely new commit IDs.
• Local Only! Never use this on commits that have already been pushed to a shared remote.

Scenario 10: How to Rearrange the Order of Commits in My Local History?

You want to change the sequence of commits for better logical flow before sharing them.

Question: How do I reorder commits in my local Git history?

Answer: Use git rebase -i (interactive rebase) and reorder the lines in the editor.

Example Code:

# Assume commits: A -- B (Bug fix) -- C (Refactor) -- D (New feature) (HEAD)
# You want to reorder to: A -- C -- B -- D

# 1. Start an interactive rebase from the commit *before* the first one you want to reorder.
git rebase -i HEAD~3

# Editor opens:
# pick <hash-B> Bug fix
# pick <hash-C> Refactor
# pick <hash-D> New feature

Simply cut and paste the lines to reorder them:

pick <hash-C> Refactor # Moved this line up
pick <hash-B> Bug fix
pick <hash-D> New feature

Save and close the editor. Git will replay the commits in the new order.

Explanation: git rebase -i allows you to completely rearrange the sequence of commits by changing their order in the text editor that opens. Git will then reapply them in the new order, creating new commit IDs.

Notes/Warnings:

• Rewrites History! New commit IDs will be generated.
• Local Only! Do not use this on commits that have already been pushed to a shared remote. This is highly disruptive to your team members.

Undoing Changes in the Remote Repository (After Pushing)

These scenarios involve commits that have already been pushed to a shared remote repository. These operations can be disruptive to collaborators and require careful consideration, and most importantly, communication with your team.

Scenario 11: How to Undo My Last Commit That I Already Pushed to the Remote (by Rewriting History)?

You have pushed a commit, but then realized it was a critical mistake (e.g., included sensitive info, broke the build, production down), and you want to completely erase it from the remote history.

Question: How do I completely remove the last pushed commit from the remote repository?

Answer: First, git reset locally to remove the commit, then git push --force-with-lease.

Example Code:

# 1. Assume your last commit was "Bad Commit" and it is pushed.
# Local and Remote: A -- B -- C (Bad Commit)

# 2. Reset your local branch back to the commit *before* "Bad Commit"
git reset --hard HEAD~1
# Local: A -- B

# 3. Now, force push your local history to the remote.
# Use --force-with-lease for safety against concurrent pushes.
git push origin <your-branch-name> --force-with-lease
# Or, the more dangerous: git push --force

Explanation:

• git reset --hard HEAD~1: This rewrites your local branch history, effectively deleting the “Bad Commit” from your local branch.
• git push --force-with-lease: This tells Git to overwrite the remote branch’s history with your local history. --force-with-lease is a safer alternative to --force as it fails if the remote branch has new commits you do not know about, preventing accidental overwrites of others’ work.

Notes/Warnings:

• EXTREMELY DANGEROUS! This rewrites shared history. If anyone else has pulled the “Bad Commit,” their local repository will now diverge from the remote, causing them problems.
• Team Communication is A MUST: NEVER do this on a shared branch without explicit coordination and agreement with your team. Inform everyone to fetch and rebase (or hard reset) their local branch to match the new remote.
• Consider git revert instead (Scenario 12) for shared history. Force pushing should be a last resort.

Scenario 12: How to Logically Undo a Specific Commit (Recent or Old) That Has Already Been Pushed to the Remote?

A problematic commit exists in the shared history (e.g., a bug was introduced, a feature needs to be rolled back), and you want to nullify its effects by creating a new commit that reverses its changes. This preserves the original commit history.

Question: How do I undo the changes of a specific commit that has already been pushed, without rewriting history?

Answer: Use git revert <commit-hash>.

Example Code:

# 1. Assume you have commits: A -- B (Buggy feature) -- C (Other work)
# And commit B has been pushed.

# 2. Find the hash of the commit you want to revert (commit B)
git log --oneline
# Example: 1a2b3c4 Buggy feature

# 3. Revert that specific commit
git revert 1a2b3c4

# Git will open an editor for the new revert commit message.
# You can accept the default or modify it.

# 4. Push the new revert commit
git push origin <your-branch-name>

# New Log: A -- B (Buggy feature) -- C (Other work) -- D (Revert "Buggy feature")

Explanation:

• git revert <commit-hash>: This command does not erase history. Instead, it creates a new commit that undoes the changes introduced by the specified commit. The original commit remains in the history, and the new “revert” commit acts as a counter-change.

Notes/Warnings:

• Safest Option for Shared History: This is the preferred and safest method for undoing changes that have already been pushed to a shared remote. It maintains a clean, linear history.
• Creates New Commit: A new commit is added to your history, which explicitly shows that a previous change was undone.
• Can Revert a Revert: If you need to re-introduce the changes later, you can git revert the “revert” commit itself.

Scenario 13: How to Undo a Merge Commit That Has Already Been Pushed to the Remote?

You merged the wrong branch, or the merge introduced significant issues, and this merge commit is now on the remote. You want to revert the state of the branch to before the merge.

Question: How do I undo a merge commit that has already been pushed to the remote?

Answer: Use git revert -m <parent-number> <merge-commit-hash>.

Example Code:

# 1. Assume you merged 'feature-branch' into 'main', and this merge commit (M) is pushed.
# Log: ... -- A -- B (main)
#                \ M (Merge B & F)
#                 \-- F (feature-branch)

# 2. Find the merge commit hash (M)
git log --oneline
# Example: 7d8e9f0 Merge branch 'feature-branch' into main

# 3. Use 'git show' to identify the parent numbers of the merge commit.
git show 7d8e9f0
# Look for 'Merge: <hash1> <hash2>'
# hash1 is usually parent 1 (your current branch's history before merge)
# hash2 is usually parent 2 (the branch you merged into current)

# 4. Revert the merge commit, choosing the parent you want to keep.
# Typically, you want to keep the history of the branch you were on (e.g., 'main').
# So, you choose parent 1.
git revert -m 1 7d8e9f0

# Git will open an editor for the new revert commit message.

# 5. Push the new revert commit
git push origin main

Explanation:

• git revert -m <parent-number> <merge-commit-hash>: Merge commits have more than one parent. The -m flag specifies which parent lineage to keep when reverting.
  • -m 1: Usually indicates you want to revert the changes introduced by the merged branch, keeping your current branch’s history. This is the most common use case.
  • -m 2: Would revert your current branch’s history up to the merge, effectively keeping the merged branch’s changes. (Rarely used).
• The revert creates a new commit that undoes the merge, preserving history.

Notes/Warnings:

• Complex! Undoing pushed merges can be complex. Ensure you understand which parent you want to preserve.
• Not a true “undo”: The merge commit itself is still in the history. You are adding a new commit that cancels out its effects.
• Team Communication: As with any operation on pushed history, communicate with your team.
• Avoid if possible: If the merge has not been pushed, git reset --hard HEAD~1 (Scenario 5, but use the merge commit’s hash) is simpler, but that rewrites history.

Scenario 14: How to Completely Remove a Remote Branch?

A feature branch has been merged and is no longer needed, or you created a branch by mistake on the remote and need to delete it.

Question: How do I delete a branch from the remote repository?

Answer: Use git push origin --delete <branch-name> or git push origin :<branch-name>.

Example Code:

# Delete a remote branch named 'old-feature-branch'
git push origin --delete old-feature-branch

# Alternative (older) syntax:
# git push origin :old-feature-branch

Explanation: These commands explicitly tell the remote to delete the specified branch. The colon syntax (:) pushes “nothing” to the remote branch, effectively deleting it.

Notes/Warnings:

• No Undo (for the branch): Once deleted, the branch pointer on the remote is gone.
• Commits Remain: While the branch pointer is deleted, the commits themselves will remain in the repository as long as they are reachable by another branch or tag. They would not be truly “deleted” until Git’s garbage collection runs and they are no longer referenced by anything.
• Permissions: You need the necessary permissions on the remote repository to delete branches.
• Coordinate: Ensure the branch is no longer needed by anyone before deleting it.

Scenario 15: How to Overwrite the Remote History with My Local History?

You have significantly rewritten your local branch’s history (e.g., after a rebase, interactive rebase, or git reset --hard for multiple commits) and now need to force-update the remote to match your new local history.

Question: How do I force my local branch’s history to overwrite the remote branch’s history?

Answer: Use git push --force-with-lease (recommended) or git push --force.

Example Code:

# 1. Assume you have done a rebase or a git reset --hard locally,
# resulting in a different history than the remote.
# Local: A -- B' -- C' (Rewritten commits)
# Remote: A -- B -- C (Old commits)

# 2. Push your local history to overwrite the remote.
git push origin <your-branch-name> --force-with-lease

# Or (less safe):
# git push --force

Explanation:

• git push --force: This command tells Git to literally overwrite whatever is on the remote branch with your local branch’s history, regardless of whether it causes conflicts or deletes commits from the remote that other users might have.
• git push --force-with-lease: This is the safer alternative. It will only force the push if your remote branch has not been updated with new commits by someone else since you last pulled. If it has, the push will fail, preventing you from accidentally overwriting concurrent work.

Notes/Warnings:

• EXTREMELY DANGEROUS! This is the most destructive operation for shared branches. It will completely replace the remote branch’s history with your local history.
• Massive Disruption: If others have pulled the old history, their local repositories will immediately diverge. They will have to perform complex git pull --rebase or git reset operations to align with the new remote history, potentially losing their work.
• Team Communication is A MUST: NEVER use --force or --force-with-lease on shared branches without first communicating with, and getting explicit agreement from, your entire team. Provide clear instructions on how they should update their local repositories.
• Avoid if possible: If you can achieve your goal with git revert (Scenario 12) instead, always prefer that for shared history.

Summary:

Scenario / Goal	Command	Description	Notes / Warnings
Local Only (Before Push):
Amend last commit message	git commit --amend	Replaces the last commit’s message.	Rewrites local history. DO NOT use on pushed commits.
Add forgotten changes to last commit	git add <file> + git commit --amend	Adds staged changes to the last commit.	Rewrites local history. DO NOT use on pushed commits.
Undo last commit (keep changes staged)	git reset --soft HEAD~1	Moves HEAD, keeps changes in staging area.	Rewrites local history.
Undo last commit (changes unstaged)	git reset HEAD~1 (--mixed default)	Moves HEAD, clears staging, keeps changes in working directory.	Rewrites local history.
Undo last commit (discard all changes)	git reset --hard HEAD~1	Moves HEAD, clears staging, discards working directory changes.	EXTREMELY DANGEROUS! POTENTIAL DATA LOSS! Use with extreme caution. Rewrites local history.
Remove specific commit (not latest)	git rebase -i HEAD~N (then drop)	Rewrites history to exclude chosen commit(s).	Rewrites history! LOCAL ONLY. Highly disruptive if pushed.
Move commit to correct branch	git reset --hard (on wrong) + git cherry-pick (on correct)	Removes commit from one branch, applies to another.	LOCAL ONLY. Creates new commit ID.
Split large commit	git reset --soft + git add/commit	Un-commits changes, then re-commits them in smaller pieces.	Rewrites history! LOCAL ONLY.
Combine/Squash multiple commits	git rebase -i (then squash/fixup)	Combines multiple commits into one.	Rewrites history! LOCAL ONLY.
Rearrange commit order	git rebase -i (reorder lines)	Changes the sequence of commits.	Rewrites history! LOCAL ONLY.
Remote (After Push):
Undo last pushed commit (rewriting remote)	git reset --hard + git push --force-with-lease	Rewrites local, then forces overwrite of remote history.	EXTREMELY DANGEROUS! Rewrites SHARED history. Use force-with-lease and COMMUNICATE WITH TEAM!
Logically undo specific pushed commit (new revert commit)	git revert <commit-hash>	Creates a new commit that undoes the changes of a previous commit.	SAFEST option for shared history. Preserves commit history.
Undo a pushed merge commit	git revert -m <parent> <merge-hash>	Creates a new commit that undoes the merge’s effects.	Complex. Preserves history. COMMUNICATE WITH TEAM!
Remove a remote branch	git push origin --delete <branch-name>	Deletes the specified branch from the remote.	Branch pointer removed, commits may still exist if reachable by other refs. Requires permissions.
Overwrite remote history with local history	git push --force-with-lease	Overwrites the remote branch’s history with your local branch’s history.	EXTREMELY DANGEROUS! Rewrites SHARED history. Use force-with-lease and COMMUNICATE WITH TEAM!

References:

• git commit: https://git-scm.com/docs/git-commit (specifically the --amend section)
• git reset: https://git-scm.com/docs/git-reset (pay close attention to --soft, --mixed, --hard)
• git rebase: https://git-scm.com/docs/git-rebase (especially the -i / --interactive section)
• git revert: https://git-scm.com/docs/git-revert
• git cherry-pick: https://git-scm.com/docs/git-cherry-pick
• git push: https://git-scm.com/docs/git-push (specifically the --force and --force-with-lease sections)
• git status: https://git-scm.com/docs/git-status
• git log: https://git-scm.com/docs/git-log

Related Items

• Undo working directory changes: https://ckdbtech.com/how-to-undo-working-directory-changes-in-git/
• Undo staged changes: https://ckdbtech.com/how-to-undo-staged-changes-in-git/
• Undo branch changes: https://ckdbtech.com/how-to-undo-branch-changes-in-git/
• Undo tag changes: https://ckdbtech.com/how-to-undo-tag-changes-in-git/

Author

Debjeet Bhowmik

Experienced Cloud & DevOps Engineer with hands-on experience in AWS, GCP, Terraform, Ansible, ELK, Docker, Git, GitLab, Python, PowerShell, Shell, and theoretical knowledge on Azure, Kubernetes & Jenkins.
In my free time, I write blogs on ckdbtech.com