If you have not yet committed that which you do not want, git does not know anything about what you have done, yet, so it is pretty easy to undo what you have done.

So you have not yet committed, the question is now whether you want to undo everything which you have done since the last commit or just some things?

So you have not yet committed and you want to undo some things, well git status will tell you exactly what you need to do. For example:

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   .gitignore
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   A
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       C

However, the git checkout in file mode is a command that cannot be recovered from—the changes which are discarded most probably cannot be recovered. Perhaps you should run git stash save -p "description" instead, and select the changes you no longer want to be stashed instead of zapping them.

So you have committed. However, before we go about fixing or removing whatever is wrong, you should first ensure that any uncommitted changes are safe, by either committing them (git commit) or by stashing them (git stash save "message") or getting rid of them. git status will help you understand whether your working directory is clean or not.

So you have committed, the question is now whether you have made your changes publicly available or not. Publishing history is seminal event.

Please note in any and all events, the recipes provided here will typically (only one exception which will self-notify) only modify the current branch you are on. Specifically any tags or branches involving the commit you are changing or a child or that commit will not be modified. You must deal with those separately. Look at gitk --all --date-order to help visualize everything what other git references might need to be updated.

There is a shortcut in case you want to discard all changes made on this branch since you have last pushed or in any event, to make your local branch identical to "upstream".

In order to discard all local commits on this branch, to make the local branch identical to the "upstream" of this branch, simply run git reset --hard @{u}

While the techniques mentioned to deal with deeper commits will work on the most recent, there are some convenient shortcuts you can take with the most recent commit.

To remove the last commit from git, you can simply run git reset --hard HEAD^ If you are removing multiple commits from the top, you can run git reset HEAD~2 to remove the last two commits. You can increase the number to remove even more commits.

To update the last commit's contents or commit message for a commit which you have not pushed or otherwise published, first you need to get the index into the correct state you wish the commit to reflect. If you are changing the commit message only, you need do nothing. If you are changing the file contents, typically you would modify the working directory and use git add as normal.

Once the index is in the correct state, then you can run git commit --amend to update the last commit. Yes, you can use "-a" if you want to avoid the git add suggested in the previous paragraph.

I call this operation "cherry-pit" since it is the inverse of a "cherry-pick". You must first identify the SHA of the commit you wish to remove. You can do this using gitk --date-order or using git log --graph --decorate --oneline You are looking for the 40 character SHA-1 hash ID (or the 7 character abbreviation). Yes, if you know the "^" or "~" shortcuts you may use those.

git rebase -p --onto SHA^ SHA

Obviously replace "SHA" with the reference you want to get rid of. The "^" in that command is literal.

However, please be warned. If some of the commits between SHA and the tip of your branch are merge commits, it is possible that git rebase -p will be unable to properly recreate them. Please inspect the resulting merge topology gitk --date-order HEAD ORIG_HEAD to ensure that git did want you wanted. If it did not, there is not really any automated recourse. You can reset back to the commit before the SHA you want to get rid of, and then cherry-pick the normal commits and manually re-merge the "bad" merges. Or you can just suffer with the inappropriate topology (perhaps creating fake merges git merge --ours otherbranch so that subsequent development work on those branches will be properly merged in with the correct merge-base).

You have not pushed but still somehow want to change all commits in all of git's history? Strange.

If the commit you are trying to change is a merge commit, or if there is a merge commit between the commit you are trying to change and the tip of the branch you are on, then you need to do some special handling of the situation.

You must first identify the SHA of the commit you wish to remove. You can do this using gitk --date-order or using git log --graph --decorate --oneline You are looking for the 40 character SHA-1 hash ID (or the 7 character abbreviation). Yes, if you know the "^" or "~" shortcuts you may use those.

git rebase -i SHA^

Obviously replace "SHA" with the reference you want to get rid of. The "^" in that command is literal.

If the problem in the old commit is just something was done incorrectly, go ahead and make a normal commit to fix the problem. Feel free to reference the old commit SHA in the commit message, and if you are into the blame-based development methodology, make fun of the person who made the mistake (or someone who recently left if you made the mistake).

The file may have been deleted or every change to that file in that commit (and all commits since then) should be destroyed. If so, you can simply checkout a version of the file which you know is good.

You must first identify the SHA of the commit containing the good version of the file. You can do this using gitk --date-order or using git log --graph --decorate --oneline You are looking for the 40 character SHA-1 hash ID (or the 7 character abbreviation). Yes, if you know the "^" or "~" shortcuts you may use those.

git checkout SHA -- path/to/filename

You can then add and commit as normal to fix the problem.

To create an positive commit to remove the effects of a simple (non-merge) commit, you must first identify the SHA of the commit you want to revert. You can do this using gitk --date-order or using git log --graph --decorate --oneline You are looking for the 40 character SHA-1 hash ID (or the 7 character abbreviation). Yes, if you know the "^" or "~" shortcuts you may use those.

git revert SHA

Oh dear. This is going to get complicated.

To create an positive commit to remove the effects of a merge commit, you must first identify the SHA of the commit you want to revert. You can do this using gitk --date-order or using git log --graph --decorate --oneline You are looking for the 40 character SHA-1 hash ID (or the 7 character abbreviation). Yes, if you know the "^" or "~" shortcuts you may use those.

Undoing the file modifications caused by the merge is about as simple as you might hope. git revert SHA. Unfortunately, this is just the tip of the iceberg. The problem is, what happens if you want to merge that branch later, perhaps months later long after you have exiled this problem from your memory, either to this branch or to some other branch this branch merged into. Well, the problem is git has it tracked in history that a merge occurred, so it is not going to attempt to remerge what it has already merged. The fact that it was later reverted is irrelevant. You could revert the revert, but that supposes that you remember that you need to do so.

If the state of a branch is contaminated beyond repair and you have pushed that branch or otherwise do not want to rewrite the existing history, then you can make a new commit which overwrites the original branch with the new one and pretends this was due to a merge. The command is a bit complicated, and will get rid of all ignored or untracked files in your working directory, so please be sure you have properly backed up everything.

In the follow example please replace $destination with the name of the branch whose contents you want to overwrite. $source should be replaced with the name of the branch whose contents are good.

You actually are being provided with two methods. The first set is more portable but generates two commits. The second knows about the current internal files git uses to do the necessary work in one commit. Only one command is different and a second command runs at a different time.

# Portable method to overwrite one branch with another
git clean -dfx
git checkout $destination
git reset --hard $source
git reset --soft ORIG_HEAD
git add -fA .
git commit -m "Rewrite $destination with $source"
git merge -s ours $source

# Hacky method to overwrite one branch with another
git clean -dfx
git checkout $destination
git reset --hard $source
git reset --soft ORIG_HEAD
git add -fA .
git rev-parse $source > .git/MERGE_HEAD
git commit -m "Rewrite $destination with $source"

<a name="pushed_old />

First make sure that it was not on a different branch. Try git log -Sfoo --all where "foo" is replaced with something unique in the commits you made. You can also search with gitk --all --date-order to see if anything looks likely.

Check your stashes, git stash list, to see if you might have stashed instead of committing. You can also run gitk --all --date-order $(git stash list | awk -F: '{print $1};') to visualize what the stashes might be associated with.

Next, you should probably look in other repositories you have lying around including ones on other hosts and in testing environments, and in your backups.

Once you are fully convinced that it is well and truly lost, you can start looking elsewhere in git. Specifically, you should first look at the reflog which contains the history of what happened to the tip of your branch for the past two weeks or so. You can of course say git log -g to view it, but it may be best visualized with gitk --all --date-order $(git log -g --pretty=%H)

Next you can look in git's lost and found. Dangling commits get generated for many good reasons including resets and rebases. Still those activities might have mislaid the commits you were interested in. These might be best visualized with gitk --all --date-order $(git fsck | grep "dangling commit" | awk '{print $3;}')

The last place you can look is in dangling blobs. These are files which have been git added but not attached to a commit for some (usually innocuous)reason. git fsck | grep "dangling blob" | while read x x s; do git show $s | less; done will show you the files, one at a time.

Copyright ⓒ 2012 Seth Robertson

Creative Commons Attribution-ShareAlike 2.5 Generic (CC BY-SA 2.5)

Thanks to the experts on #git for review, feedback, and ideas.

Comments and improvements welcome.

Add them below, or discuss with SethRobertson (and others) on #git