### Don't let an error in a git command wipe out days of work.
Image by :opensource.com
Today my colleague almost lost everything that he did over four days of work. Because of an incorrect**git**command, he dropped the changes he'd saved on[stash][20]. After this sad episode, we looked for a way to try to recoverhis work... and we did it!
First a warning: When you are implementing a big feature, split it in small pieces and commit it regularly. It's not a good idea to work for a long time without committing your changes.
Now that we've gotten that out of the way, let's demonstrate how to recoverchanges accidentally droppedfrom stash.
My example repository, which has only one source file,**main.c**, looks like this:
### [missing_data_from_stash_01.jpeg][9]
José Guilherme Vanz,[CC BY][3]
I'll start to code something. For this example, I do not need to make a big change, just something to put in the stash, soI will just add a new line. The**git-diff**output should be:
Now, suppose that I want to pull some new changes from a remote repository, but I'm not ready to commit my change. Instead, I decide to stash it, pull the remote repository's changes, then apply my changeback to the master. I execute the following command to move my changeto stash:
```
git stash
```
Looking into the stash with**git stash list**, I can see my changethere:
### [missing_data_from_stash_06.jpeg][13]
José Guilherme Vanz,[CC BY][5]
My code is in a safe place and the master branch is clean (I can check this with**git status**). Now I just need to pull the remote repository changes, then apply my change on the master, and I should be set.
But I accidentally execute:
```
git stash drop
```
which deletes the stash, instead of:
```
git stash pop
```
which would have applied the stash before dropping it from my stack. If I execute**git stash list**again, I can see I dropped my changefrom the stash without applying it on the master branch. OMG! Who can help me?
Good news:**git**did not delete the object that contains my change; it just removed the reference to it. To prove this, I use the**git-fsck**command, which verifies the connectivity and validity of the objects in the database. Here's the output after I executed the**git-fsck**command on the repository:
### [missing_data_from_stash_07.jpeg][14]
José Guilherme Vanz,[CC BY][6]
With the**--unreachable**argument, I asked**git-fsck**to show me the objects that are unreachable. As you can see, it showed no unreachable objects. After I dropped the changes on my stash, I executed the same command, and received a different output:
### [missing_data_from_stash_08.jpeg][15]
José Guilherme Vanz,[CC BY][7]
Now there are three unreachable objects. But which one is my change? Actually, I don't know. I have to search for it by executing the**git-show**command to see each object.
### [missing_data_from_stash_09.jpeg][16]
José Guilherme Vanz,[CC BY][8]
There it is! The ID**95ccbd927ad4cd413ee2a28014c81454f4ede82c**corresponds tomy change. Now that I found the missing change, I can recover it! One solution is check out the ID into a new branch or apply the commit directly. If you have the ID of the object with your changes, you can decide the best way to put changes on the master branch again. For this example, I will use**git-stash**to apply the commit on my master branch again.
Another important thing to remember is**git**runs its garbage collector periodically. After a**gc**execution, you can no longer see the unreachable objects using**git-fsck**.
_This article was[originally published][18]on the author's blog and is reprinted with permission._
