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.
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.
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.
- I am in the middle of a bad merge
- I am in the middle of a bad rebase
- Yes, I committed
- No, I have not yet committed
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.
- I want to discard all unpushed changes
- I want to make my branch identical to some non-upstream ref
- I want to fix some unpushed changes
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 REFObviously 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.
- I want to change the most recent commit
- I want to discard the most recent commit(s)
- I want to undo the last git operation(s) affecting the HEAD/tip of my branch (most useful for rebase, reset, or --amend)
- I want to change an older 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^ SHAObviously 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).
Do you want to remove/change/rename a particular file/directory from all commits during all of git's history
- Yes please, I want to make a change involving all git commits
- No, I only want to change a single commit
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-orderor usinggit log --graph --decorate --onelineYou 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 branchoutput 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 -pwill be unable to properly recreate them. Please inspect the resulting merge topologygitk --date-order HEAD ORIG_HEADto 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 mergesgit merge --ours otherbranchso 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.
- Yes, I can make a new commit but the bad commit trashed a particular file in error (among other good things I want to keep)
- Yes, I can make a new commit and the bad commit is a merge commit I want to totally remove
- Yes, I can make a new commit but the bad commit is a simple commit I want to totally remove
- Yes, I can make a new commit and the bad commit has an error in it I want to fix
- Yes, I can make a new commit but history is all messed up and I have a replacement branch
- No, I am a bad person and must rewrite published history
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/filenameObviously 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 SHAObviously 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 $sourceor
# 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 SHAYou could also link that old state to a new branch name using
git checkout -b newbranch SHAObviously 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