Skip to content

Instantly share code, notes, and snippets.

@yaodong
Forked from silent1mezzo/0fixup.md
Created July 31, 2024 21:09
Show Gist options
  • Save yaodong/0def27e9849a979406622a2471ac9222 to your computer and use it in GitHub Desktop.
Save yaodong/0def27e9849a979406622a2471ac9222 to your computer and use it in GitHub Desktop.
On undoing, fixing, or removing commits in git

A git choose-your-own-adventure!

This document is an attempt to be a fairly comprehensive guide to recovering from what you did not mean to do when using git. It isn't that git is so complicated that you need a large document to take care or your particular problem, it is more that the set of things that you might have done is so large that different techniques are needed depending on exactly what you have done and what you want to have happen.

If you have problems after clicking through this document, please document what the links you clicked on are when asking for further help (on #git or elsewhere) which will explain very precisely what you were trying to do and that you at least tried to help yourself. Sorry, due to the limitations of github we cannot gather the history for simple copy-paste.

First step

Strongly consider taking a backup of your current working directory and .git to avoid any possibility of losing data as a result of the use or misuse of these instructions. We promise to laugh at you if you fail to take a backup and regret it later.

Answer the questions posed by clicking the link for that section. A section with no links is a terminal node and you should have solved your problem by completing the suggestions posed by that node (if not, then report the chain of answers you made on #git or some other git resource and explain further why the proposed answer doesn't help). This is not a document to read linearly.

Proceed to the first question

Due to previous activities (thrashing about), you may have lost some work which you would like to find and restore. Alternately, you may have made some changes which you would like to fix.

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 everything. Well, best practice is for you to stash the changes in case you were mistaken and later decide that you really wanted them after all. git stash save "description of changes". You can revisit those stashes later git stash list and decide whether to git stash drop them after some time has past. Please note that untracked and ignored files are not stashed by default. See "--include-untracked" and "--all" for stash options to handle those two cases.

However, perhaps you are confident (or arrogant) enough to know for sure that you will never ever want the uncommitted changes. If so, you can run git reset --hard, however please be quite aware that this is almost certainly a completely unrecoverable operation. Any changes which are removed here cannot be restored later. This will not delete untracked or ignored files. Those can be deleted with git clean -nd git clean -ndX respectively, or git clean -ndx for both at once. Well, actually those command do not delete the files. They show what files will be deleted. Replace the "n" in "-nd…" with "f" to actually delete the files. Best practice is to ensure you are not deleting what you should not by looking at the moribund filenames first.

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.

Also note that these commands will fix up the referenced commits in your repository. There will be reflog'd and dangling commits holding the state you just corrected. This is normally a good thing and it will eventually go away by itself, but if for some reason you want to cut your seat belts, you can expire the reflog now and garbage collect with immediate pruning.

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". Upstream, for local tracking branches, is the place you get history from when you git pull: typically for master it might be origin/master. There is a variant of this option which lets you make your local branch identical to some other branch or ref.

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}

If instead of discarding all local commits, you can make your branch identical to some other branch, tag, ref, or SHA that exists on your system.

The first thing you need to do is identify the SHA or ref of the good state of your branch. You can do this by looking at the output of git branch -a; git tag, git log --all or, my preference, you can look graphically at gitk --all --date-order

Once you have found the correct state of your branch, you can get to that state by running

git reset --hard REF

Obviously replace "ref" in both commands with the reference or SHA you want to get back to.

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.

If you want to save the commits on a new branch name, then run git branch newbranchname BEFORE doing the git reset.

To update the last commit's contents, author, 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.

Note if you wish to restore a file to a known good state, you can use git checkout GOODSHA -- path/to/filename.

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. You can also use --author to change the author information.

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).

## Changing all commits during all of git's history

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

You want to use the git filter-branch command to perform this action. This command is quite involved and complex, so I will simply point you at the manual page and remind you that best practice is to always use --tag-name-filter cat -- --all unless you are really sure you know what you are doing.

BTW, this is the one command I referred to earlier which will update all tags and branches, at least if you use the best practice arguments.

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.

You will be dumped in an editor with a bunch of lines starting with pick. The oldest commit, the one you are probably interested in changing, is first. You will want to change the "pick" to "reword" or "edit", or perhaps even "squash" depending on what your goal is. Please read the manual page for more information.

When using "edit", to change contents or author, when you are dumped into the shell to make your change, well make your change, git add as normal, and then run git commit --amend (including changing the author information with --author). When you are satisfied, you should run git rebase --continue

Oh dear. This is going to get a little complicated. It should all work out, though. You will need to use a nonce branch as a placeholder. I will call the nonce branch "nonce" in the following example. However, you may use any branch name that is not currently in use. You can delete it immediately after you are done.

  • Identify the SHA of the commit you wish to modify.

    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.

  • Remember the name of the branch you are currently on

    The line with a star on it in the git branch output is the branch you are currently on. I will use "$master" in this example, but substitute your branch name for "$master" in the following commands.

  • Create and checkout a nonce branch pointing at that commit.

git checkout nonce SHA


    Obviously replace "SHA" with the reference you want to modify.

* Modify the commit

    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.

    Note if you wish to restore a file to a known good state, you can use
    `git checkout GOODSHA -- path/to/filename`.

    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.

    If the commit you are updating is a merge commit, ensure that the log
    message reflects that.

* Put the remaining commits after the new one you just created

    Remembering to substitute the correct branch name for $master

    ```shell
git rebase -p --onto $(git rev-parse nonce) HEAD^ $master
  • Validate that the topology is still good

    If some of the commits after the commit you changed are merge commits, please be warned. 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).

  • Delete the nonce branch

    You don't need it. It was just there to communicate an SHA between two steps in the above process. git branch -d nonce

Rewriting public history is a bad idea. It requires everyone else to do special things and you must publicly announce your failure. Ideally you will create either a commit to just fix the problem, or a new git revert commit to create a new commit which undoes what the commit target of the revert did.

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

Obviously replace "SHA" with the reference that is good. 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

Obviously replace "SHA" with the reference you want to revert.

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.

Another option is to abandon the branch you merged from, recreate it from the previous merge-base with the commits since then rebased or cherry-picked over, and use the recreated branch from now on. Then the new branch is unrelated and will merge properly. Of course, if you have pushed the donor branch you cannot use the same name (that would be rewriting public history and is bad) so everyone needs to remember to use the new branch. Hopefully you have something like gitolite where you can close the old branch name.

At this time, I will not walk you through the process of recreating the donor branch. Given sufficient demand I can try to add that. However, if you look at howto/revert-a-faulty-merge.txt which is shipped as part of the git distribution, it will provide more words than you can shake a stick at.

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 in two commits
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

or

# Hacky method to overwrite one branch with another in one commit
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"

Hopefully you read the previous reference and fully understand why this is bad and what you have to tell everyone else to do in order to recover from this condition. Assuming this, you simply need to go to the parts of this document which assume that you have not yet pushed and do them as normal. Then you need to do a "force push" git push -f to thrust your updated history upon everyone else. As you read in the reference, this may be denied by default by your upstream repository (see git config receive.denyNonFastForwards, but can be disabled (temporarily I suggest) if you have access to the server. You then will need to send mail to everyone who might have pulled the history telling them that history was rewritten and they need to git pull --rebase and do a bit of history rewriting of their own if they branched or tagged from the now outdated history.

Proceed with fixing the old commit.

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 branches for the past two weeks or so. You can of course say git log -g or git reflog to view it, but it may be best visualized with gitk --all --date-order $(git reflog --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.

Once you find the changes you are interested in, there are several ways you can proceed. . You can git reset --hard SHA your current branch to the history and current state of that SHA (probably not recommended for stashes), you can git branch newbranch SHA to link the old history to a new branch name (also not recommended for stashes), you can git stash apply SHA (for the non-index commit in a git-stash), you can git stash merge SHA or git cherry-pick SHA (for either part of a stash or non-stashes), etc.

Practically every git operation which affects the repository is recorded in the git reflog. You may then use the reflog to look at the state of the branches at previous times or even go back to the state of the local branch at the time.

While this happens for every git command affecting HEAD, it is usually most interesting when attempting to recover from a bad rebase or reset or an --amend'ed commit. There are better ways (listed by the rest of this document) from recovering from the more mundane reflog updates.

The first thing you need to do is identify the SHA of the good state of your branch. You can do this by looking at the output of git log -g or, my preference, you can look graphically at gitk --all --date-order $(git log -g --pretty=%H)

Once you have found the correct state of your branch, you can get back to that state by running

git reset --hard SHA

You could also link that old state to a new branch name using

git checkout -b newbranch SHA

Obviously replace "SHA" in both commands with the reference you want to get back to.

Note that any other commits you have performed since you did that "bad" operation will then be lost. You could git cherry-pick or git rebase -p --onto those other commits over.

So, you were in the middle of a merge, have encountered one or more conflicts, and you have now decided that it was a big mistake and want to get out of the merge.

The fastest way out of the merge is git merge --abort

So, you were in the middle of a rebase, have encountered one or more conflicts, and you have now decided that it was a big mistake and want to get out of the merge.

The fastest way out of the merge is git rebase --abort

Information is not promised or guaranteed to be correct, current, or complete, and may be out of date and may contain technical inaccuracies or typographical errors. Any reliance on this material is at your own risk. No one assumes any responsibility (and everyone expressly disclaims responsibility) for updates to keep information current or to ensure the accuracy or completeness of any posted information. Accordingly, you should confirm the accuracy and completeness of all posted information before making any decision related to any and all matters described.

Copyright ⓒ 2012 Seth Robertson

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

http://creativecommons.org/licenses/by-sa/2.5/

I would appreciate changes being sent back to me, being notified if this is used or highlighted in some special way, and links being maintained back to the authoritative source. Thanks.

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

Comments and improvements welcome.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment