With git it is nearly impossible to lose your work after you commit it.

Even after running some “destructive” commands like git reset --hard or git rebase, there’s a very good chance you will be able to get your work back.

However, if you have not commited your changes there is one command that can wipe them all out and is impossible to get them back:

git checkout .

Git uses the checkout command for many things: Creating branches, switching between branches, moving to specific commits and, of course, undoing your changes.

The command above basically means “Undo all the changes I have not committed yet, from this directory and all its subdirectories”. Pretty destructive, don’t you think? Especially if you’re like me and you have aliased checkout to co which puts only 8 characters between you and losing your last hour’s worth of work.

The solution

The solution to this is to put this alias to your ~/.gitconfig:

[alias]
    co = "!f(){ if [ \"$1\" = '.' ]; then echo 'Nope'; else git checkout [email protected]; fi; }; f"

This basically tells git that whenever you type git co SOMETHING to run a function. The function checks if its first argument $1 is . in which case it will just print “Nope” otherwise it will pass all its arguments [email protected] to git checkout as intended.

The catch with running functions in your aliases is that all the functions are executed at the top level of your repository (the place where your .git/ dir is). This means that if you are not there you cannot checkout individual files, unless you specify the full path to them or at least provide their relative-to-the-top-level path.

I also tried using the $GIT_PREFIX variable which contains the path to the root of your repository but then it screws up branch operations ¯\_(ツ)_/¯

If you find a way around this send me a message on Twitter.

Alternative

Now, there are many valid use cases that you may want to revert all your changes, maybe to test something else, or to start clean, and there is a non destructive way to do that, by stashing your changes away with git stash. In case you want to bring the changes back, they are just a git stash pop away.

Bottom line

I had this alias in my ~/.gitconfig for the last few months and it stopped me a couple of times from losing all my changes when in reality I’ve been meaning to only checkout a single directory. I did not run into the drawback because I almost always work from the top level of the repo so it has not been an issue for me.

Let me know if you found this useful and/or how this could be improved.