Summary Ever accidentally lose some work because you didn't commit to your version control system's repository? That won't happen anymore if you're using Git.

Git, the distributed version-control system, has won me over. That's not to say that svn is a bad choice, only that I now prefer git when starting anew. It's also got a highly effective, if somewhat bland, GUI interface provided by git-gui.

I'm happy to see more people in my local community using Git, or at least thinking about it. A recent mishap and its happy ending put another solid notch in git's column for me, since I'm not sure that the result would have been the same if I were using another VCS.

Whoops

I just accidentally deleted over 40 files in a project I'm working on. And some of those files had local modifications to them, representing about 45 minutes of work or so. It therefore wasn't safe to just restore from the last commit. What to do?

Had I been using VSS, CVS, Subversion or most other version control systems, this would be an unfortunate and frustrating loss of time. In most version-control environments, whatever isn't committed is gone forever. Lose your local copies and you've lost everything.

Git to the rescue

Git, however, has the concept of an index, often called the staging area. In the staging area, you assemble the changes you're making into a meaningful unit that is then committed to your desired repository.

Typically, changes are first added to the index, then committed to a repository. Each commit generates a unique identifier.

Whenever you perform git add, you add changes that have not yet been staged to the staging area. Note that you're adding individual changes, not files. Although Git is of course aware of files, it is effectively storing changes and what they apply to, not the contents of files themselves. By default git assumes you would like to add all the changes of each file you mention, but you can use git add -p to enter an interactive mode where you select desired changes.

Periodically adding changes to the staging area is thus a good idea; it signals that you would like to eventually commit these changes and that they are important.

Restoring the deleted files

Because our changes are living in the staging area, restoring the deleted files is almost trivial. To see the difference between the staging area and what's in the working tree, you can invoke git ls-files. Specifically, we're interested in deleted files:

$ git ls-files --deleted

Assuming that looks like what you want, go ahead and checkout each file back from the index.

$ git ls-files -d | xargs git checkout --

Huzzah; your work is saved! Not bad for two commands.

Some additional notes

Normally, if you use git checkout without specifying a file path, you'll update your index and working tree to reflect whatever current or new branch you'd like to look at.

However, in this case, we pass a list of paths to git checkout originating from git ls-files. When you use git checkout and you specify a local path git checks any changes out from the index instead. This restores files to their state the last time you added them.

You can read more information about how git checkout works at the online manual.