Git revolutionized version control systems with its efficient tracking of code changes and collaboration capabilities. Despite its numerous advantages, at times, users may hesitate to utilize Git, fearing that it cannot rectify an issue or that they’ve made an irreversible mistake.
The XKCD comic humorously illustrates this common misconception among developers: the belief that they’ve made an irreversible mistake in Git and need to start over from scratch.
However, in reality, Git offers robust mechanisms for tracking changes and recovering from errors like lost code, denying the belief that such errors are irreversible. Anything that has been committed to Git, no matter how seemingly lost or irretrievable, can be restored, the key point being that it must be committed. So remember to commit often.
This fundamental principle of Git provides developers with a sense of security, knowing that their work is safeguarded against accidental deletion or corruption. Whether it’s a critical piece of functionality accidentally removed or an entire branch mistakenly deleted, Git offers a safety net for restoring lost code.
As seen in the comic above, one of the primary reasons why individuals are unable to fully utilize Git is that they focus on memorizing commands rather than understanding how Git works and its underlying concepts. Therefore, this post will mostly focus on the fundamentals behind how the Git reflog works, with commands for its common use cases provided at the end.
What is Git reflog?
Git has an extensive logging mechanism, you may already be familiar with git log. Another key component of this logging system is the Git reflog (short for reference log), which serves as a comprehensive record of all commits and changes within the repository. This built-in Git command serves as a vital safety net, documenting the history of commits, branch creations, deletions, and other alterations. Even when these changes are no longer visible in regular Git logs, the reflog retains a comprehensive record, enabling the recovery of lost or deleted commits and branches.
When and how to use Git reflog?
Git reflog is useful in scenarios such as:
- Recovering lost commits
- Recovering lost branches
- Reverting mistaken resets
- Recovering from a mistaken rebase or merge
Before going into usage of Git reflog, one should preferably know about references in Git, particularly about HEAD reference. HEAD refers to the current snapshot of your project. It’s essentially a pointer to the latest commit in the branch you’re currently working on. As you perform various actions in Git, such as committing changes, switching branches, merging branches, or resetting to a previous state, the HEAD pointer moves accordingly. For example, when you commit changes, HEAD moves to the new commit to reflect the latest state of your project. Similarly, when you switch to another branch, merge a branch, do a reset, HEAD changes accordingly.
Git reflog serves as a comprehensive log of all reference movements within your repository, not just limited to the HEAD reference. It records actions such as commits, branch creations, deletions, merges, resets, and rebases. This log proves invaluable for recovering lost or deleted commits, branches, or changes, offering a detailed history of the repository’s movements.
On any Git repository, when you type git reflog, it will output the reflog of the HEAD reference by default.
Here’s a sample output of git reflog command:
abcdef1 HEAD@{0}: commit: Added new feature XYZ
1234567 HEAD@{1}: checkout: moving from feature/abc to master
abcdef1 HEAD@{2}: commit: Fixed bug #123
2345678 HEAD@{3}: reset: moving to HEAD^
7890123 HEAD@{4}: commit: Initial commit
Here’s what each column signifies:
- Commit hash: This column displays the unique identifier (SHA) of each commit. It identifies the specific commit associated with the recorded action.
- Reference: In the provided output, this is denoted by HEAD@{n}, where n represents the number of steps backward from the current HEAD position. It indicates the position of the HEAD pointer after each action relative to its previous state. For example, HEAD@{2} means “where HEAD used to be two actions ago”
- Description: This column provides a brief description of the action that caused the HEAD movement. It describes the nature of the action performed, such as a commit, checkout, reset, or rebase, along with any relevant details.
The reflog entries for a specific reference, such as a branch can be viewed by using the git reflog command. For example, if you run git reflog master, it will show the reflog for the master branch.
Commands for recovering from mistakes
1. Restoring lost commits:
Search for the SHA of the relevant lost commit in the reflog output.
Use the following command to cherry-pick the lost commit using its SHA:
git cherry-pick
2. Recovering deleted branches:
Identify the commit SHA of the deleted branch, look for the entry where the branch was deleted in the reflog output.
Use the following command to restore the deleted branch:
git checkout -b
3. Reverting mistaken resets:
Locate the commit SHA just before the mistaken reset in the reflog output.
Use the following command to revert the reset operation:
git reset –hard
4. Recovering from a mistaken rebase or merge:
Identify the SHA of the commit before the rebase or merge: Find the commit SHA just before the rebase or merge operation in the reflog output.
Use the following command to reset the repository to the state before the rebase or merge:
git reset –hard