Has it ever happened to you that you have woken up😰 from deep sleep with the nightmare that the code on which you have been working on for the past 2 weeks has vanished in thin air?
That in the dream, you accidentally performed a
git reset --hard origin/master
on a branch and later realized you were supposed to do that on a different branch & now all you want to do is go to the washroom and cry yourself out?
If answers to the above question is 'yes', then your life is going to change today. (Dramatic music plays 🎶)
Git provides a very not-so-known command that allows you a high level of control over your git repo than you could ever imagine. That command, ladies and gentlemen, is (🥁🥁Drumroll🥁🥁)
git reflog
Git reflog is amazing with respect to the ways in which it helps you in recovering your project history. You can recover almost anything that you had committed at some point of time in the past using the reflog command.
Usage
Here is an example of the command output:
Now, if you want to take your code base to the state it was at time time of any of these commits, just do
git reset --hard <sha-id>
Else, if you just wanted to 'borrow' the code from any one of those commits, do a:
git cherry-pick <sha-id>
And that's how you sleep🛌 peacefully at night henceforth.
Cheers!
If you liked that, Check out other content of mine that got moderately famous:
Top comments (10)
Of no use now.... but one day I suspect this will be a lifesaver. Thanks!
The Git syntax is ambiguous and vague. The documentation typically describes commands that could have multiple meanings in equally confusing terms.
For example, the Git Cheat Sheet definition for the git "rebase" command is "apply any commits of current branch ahead of specified one". Is this clear? Does everyone understand what the "rebase" command actually does?
Tools such as Git should use syntax that clearly describes the direction and results of the command. Modern documentation should strive to follow standards such as the Simplified Technical English standard. The goal of Simplified Technical English is clarity. One of the key rules of Simplified Technical English is to write so that the message cannot be interpreted in multiple ways.
The syntax of a development tool should also follow the goals of Simplified Technical English.
Git syntax and documentation are the poster-children for ambiguity.
Git takes a substantial learning curve. Very few developers pick it up in a day. The underlying concepts are straight-forward. Imagine the pain, suffering, and costs that could be eliminated if Git syntax and documentation were developed with clarity in mind.
I have used Git for a year. Today, I lost six hours trying to figure out the best way to remove files from a pull-request.
It's good to know, thus I believe once git's garbage collection run it ain't work anymore, does it? Don't get me wrong, it's not a hate comment 😉
Exactly. It is not a Back to the Future feature but pretty reliable to get you out of one of those OMG what have I done moments.
The trick is that
git gcpreserves all commits of all reflogs.I can vouch for this! Reflog saved me a world of pain when I first
screwed up onwas learning git.What about restoring uncommitted history or rm -rf'ing a repository with un-pushed commits?
alias rm="git push && rm" 😉
Haha.. 😆
I'm not sure. Maybe not something got could help us with. Well have to work with disk managers and salvage deleted partitions.