The main difference is that the affected files now are unstaged.Ī hard reset is pretty much nuking the specified repo history. That you can either continue working on or discard.Ī mixed reset is pretty much the same thing as a soft reset. Script.js is now reset to it’s previous version, with a pending uncommited change There were 4 commits, nowĪll the changed files have also been uncommited and are now staged. I’ll explain the differences shortly.Īfter making a soft reset, notice that all commit(s) made after the commit we resetted to now are gone. In most scenarios you are fine with selecting Soft or Mixed depending on personal preference. Your choice will affect the state of the changes you are resetting. I am now given three options - Soft, Mixed or Hard reset. I start out by right clicking the commit I want to reset back to: I want to undo the last commit and go back in time to the previous commit, “Added script.js”, which I know contains the last working version The horror! But fear not, this is easily fixed. But only after I’ve made the last commit, I discover that I’ve accidentally I have for this demo created a repo with a few commits. Typo, bug etc that you want to edit or remove.Īnd in GitKraken this is of course only a few clicks away. If you want some more options on what to do in this situation, Mathieu Martin’s illustrated guide to recovering lost commits with Git has plenty for you.Reset is a very neat feature in Git if you want to go back in time and make a change to one or several commits. If you have other ways let us know in the comments! From here you can continue to work as normal! You could also checkout the SHA1 into a new branch, but really a merge is the fastest and easiest way to restore that lost commit once you have the hash. This command will bring your lost changes back and make sure that HEAD is pointing at the commit. If we want to get immediately apply it back onto our current branch, doing a git merge will recover the commit:Ģ files changed, 6 insertions(+), 2 deletions(-) You can also see the that git knows about the commit still by using the reflog command:ħc61179. We can prove that git knows about the commit still with the fsck command:ĭangling commit 7c61179cbe51c050c5520b4399f7b14eec943754 We need the SHA1 of the commit so we can bring it back. At this point if we wanted it back we could just git pull, but we’re assuming that only our local repository knows about the commit. So our HEAD has been backed up by one commit. HEAD is now at 39ba87b Fixing about and submit pages so they don't look stupidģ9ba87bf28b5bb223feffafb59638f6f46908cac HEAD So unless you’ve ran a git gc since you tossed it, you should be in the clear to restore it.įor these examples, I’m working with the code for this blog. It’s still in git’s datastore, waiting for the next garbage collection to clean it up. When you do a reset, the commit you threw out goes to a “dangling” state. Don’t fear, git should still have your commit. You’ll never be able to implement that algorithm that perfectly twice, so you need it back. Well, it turns out you really did need those changes. So, you just did a git reset -hard HEAD^ and threw out your last commit.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |