Git-ing Out Of Trouble
Git is a popular and powerful tool for managing source code, documentation, and really anything else made of text that you’d like to keep track of. With great power comes quite a lot of complexity however, and it can be easy to get into a tangle using this tool. With that in mind, I thought I’d share some tips for how to “undo” with git.
The closest thing to an undo command in git is git reset. You can undo various levels of thing, right up to throwing away changes that are already in your history. Let’s take a look at some examples, in order of severity.
Git reset without any additional arguments (technically it defaults to git reset –mixed) will simply unstage your changes. The changes will still be there, the files won’t change, but the changes you had already staged for your next commit will no longer be staged. Instead, you’ll see locally modified files. This is useful if you realise that you need to commit only part of the local modifications; git reset lets you unstage everything without losing changes, and then stage the ones you want.
Git Reset –Hard
Using the –hard switch is more destructive. This will discard all changes since the last commit, regardless of whether they were staged or not. It’s relatively difficult to lose work in git, but this is an excellent way of achieving just that! It’s very useful though when you realise you’ve gone off on a tangent or find yourself in a dead end, as git reset –hard will just put you back to where you were when you last committed. Personally I find it helpful to commit before going for lunch, as immediately afterwards seems to be my peak time for tangents and I can then easily rescue myself.
Git Reset –Hard [Revision]
Using –hard with a specific SHA1 will throw away everything in your working copy including staging area, and the commits since the one you name here. This is great if you’re regretting something, or have committed to the wrong branch (make a new branch from here, then use this technique on the existing branch to remove your accidental commits. I do this one a lot too). Use with caution though, if you have already pushed your branch to somewhere else, your next push will need to use the -f switch to force the push – and if anyone has pulled your changes, they are very likely to have problems so this isn’t a recommended approach for already-pushed changes.
Hopefully there are some tips there that will help you to get out of trouble in the unlikely event that you need them. When things go wrong, stay calm and remember that it happens to the best of us!
Lorna Jane Mitchell is a web development consultant and trainer from Leeds in the UK, specialising in open source technologies, data-related problems, and APIs. She is also an open source project lead, regular conference speaker, prolific blogger, and author of PHP Web Services, published by O’Reilly.
Do you want to know more about Git?
Lorna will be giving a full day tutorial – ‘Git for Development Teams’ on Thursday 6th February 2014 in London. This tutorial is organized by FLOSS UK and O’Reilly UK Ltd. Click here for further details. Please note that the early bird rates are available until January 14th.
Leave a Reply