Git became already a standard in software engineering. There is no need to talk about the importance of the version control system nowadays. Even more, it is hard to imagine any kind of project without it. Constant changes to the code and continuous release cycles require that.
So git. The most typical git-flow would be: create a new branch, write some code, commit and push changes to the remote repository. This is a very simplified version of the git-flow. Usually, there are more commands we do (for example, merging, rebasing etc.). And as human beings, we tend to make mistakes. Many reasons can be behind: bad day, being tired, get distracted or you name it. Let me tell you a personal short story with a happy end.
I started my day by fixing an issue in the application. Few commits, create a pull request, get approval, and ready to be merged to master. Since master was a few commits ahead and was causing merge conflicts to my branch, I decided to do a rebase of my branch. This is how it looked after the command
git rebase -i master
Did you spot the last line written in all caps? Guess what I did? Yes, you are right — I removed the second commit and saved changes (don’t ask me why 🤦♂). The second commit was gone along with all the changes made there. That was a disappointing situation as many changes were there. So I started thinking was I can do?
Git log contains now only the first commit, so there is no way to revert that commit. In fact, I needed to revert
git rebase
operation. After revisiting git documentation solution was found. It is git reflog (stands for reference log). Probably, not many of you have heard about it. It is not a common command we would use in everyday life. That command provides a mechanism to record all operations related to files. Think about it as a logger of all actions you do. But don’t mix up with git log
command:git log
returns the list of commits for the repositorygit reflog
returns the list of actions on the repositoryBelow you can find the output of the
git reflog
command for my repository:This is exactly what we were looking for — the history of actions and manipulations. Except the default option to view it, there is also a subcommand to delete a history entry. In my head the following picture appeared: if I delete the entry, then the entire action will be rolled back as it never existed. After running the command
git reflog delete HEAD@{0}
the output of the git reflog
has the following output:Now we can see that the reference to the rebase operation doesn’t exist anymore, however, that doesn’t fix the problem — commit still was lost and didn’t appear in
git log
. Therefore, deleting a reflog entry deletes only entry, but doesn’t do anything with the code changes.Instead, another idea came to my mind: we know the SHA hash of the second commit (according to the screenshot is
1d9d4bf2f
). So we can restore that commit with the command git cherry-pick
. Running git cherry-pick 1d9d4bf2f
does all magic for us. The lost commit is back with all necessary changes as nothing changed. Voilà!Now you should know what to do if someday you or your colleague messed up with the repository and few commits disappeared.
git reflog
is not well-known but indeed a powerful tool to recover from the disaster. Happy coding!