Go to a particular revision
Categories:
Navigating Git History: How to Go to a Particular Revision

Learn how to effectively navigate and inspect specific revisions in your Git repository, whether you need to view old code, debug, or revert changes.
Git's power lies in its ability to track every change made to your project. This history is a valuable resource for understanding how your codebase evolved, identifying when a bug was introduced, or even recovering lost work. This article will guide you through the essential commands and techniques to 'go to' a particular revision, allowing you to inspect, compare, and interact with your project at any point in its history.
Understanding Git Revisions
Before we dive into commands, it's crucial to understand how Git identifies revisions. Every change committed to your repository is assigned a unique SHA-1 hash, a 40-character hexadecimal string. This hash is the definitive identifier for a commit. Additionally, Git provides more human-friendly ways to refer to commits, such as branch names, tags, and relative references (e.g., HEAD~1
).
graph TD A[Initial Commit] --> B[Feature A] B --> C[Bugfix] C --> D[Feature B] D --> E[HEAD (Current Commit)] subgraph References E -- HEAD --> E D -- master --> D C -- tag: v1.0 --> C B -- HEAD~2 --> B end
Git revision references: SHA-1, HEAD, branches, and tags.
Inspecting a Specific Revision
Often, you don't want to change your current working directory; you just want to see what a file looked like at a specific commit or inspect the commit's metadata. Git provides several commands for this purpose without altering your current branch or files.
git show <commit-hash>
git show HEAD~2
git show master~1
git show v1.0:path/to/file.js
View commit details or file content at a specific revision.
The git show
command is versatile. When given a commit hash, it displays the commit's metadata (author, date, message) and the diff introduced by that commit. If you append a file path after a colon, it will show the content of that specific file at that revision. This is incredibly useful for quick inspections.
git log --oneline --graph --decorate
git log -p <commit-hash>
git diff <commit-hash> <another-commit-hash>
Explore commit history and compare revisions.
git log
helps you find the commit hash you're looking for. The --oneline --graph --decorate
options provide a compact, visual representation of your history. git diff
allows you to compare the state of your repository between any two given revisions.
Temporarily Moving to a Revision (Detached HEAD)
If you need to compile, run tests, or make temporary changes based on an older version of your code, you can 'checkout' a specific commit. This puts your repository into a 'detached HEAD' state. In this state, you are directly on a commit, not on a branch. Any new commits you make will not be part of any branch unless you explicitly create one.
git checkout <commit-hash>
git checkout HEAD~3
git checkout v1.0
Checkout a specific commit, entering detached HEAD state.
flowchart LR A[master branch] --> B(Commit 1) B --> C(Commit 2) C --> D(Commit 3) D -- HEAD --> D subgraph Detached HEAD C -- git checkout C --> C C -- HEAD --> C C -- New Commit X --> X end X -- (unreachable by master) --> X
Flow of entering and working in a detached HEAD state.
1. Find the desired commit
Use git log --oneline --graph
to identify the SHA-1 hash or a reference (like a tag or HEAD~N
) of the commit you want to visit.
2. Checkout the commit
Execute git checkout <commit-reference>
(e.g., git checkout a1b2c3d
or git checkout HEAD~5
). Your working directory and index will be updated to reflect the state of the repository at that commit. Git will inform you that you are in a 'detached HEAD' state.
3. Inspect and work
You can now view files, run tests, or even make temporary changes. Remember that any new commits you make will not be on a branch.
4. Return to a branch
To return to your previous branch (e.g., master
or main
), simply run git checkout <branch-name>
. If you made commits in the detached HEAD state that you want to keep, create a new branch before switching back: git checkout -b new-feature-branch
.
Reverting or Resetting to a Revision
Sometimes, 'going to' a revision means undoing changes or permanently moving your branch pointer. This involves commands like git revert
and git reset
, which have different implications for your project history.
git revert <commit-hash>
Create a new commit that undoes the changes of a previous commit.
git revert
is a safe way to undo changes because it creates a new commit that reverses the effects of a specified commit, preserving the project history. This is ideal for shared repositories.
git reset --soft <commit-hash>
git reset --mixed <commit-hash> (default)
git reset --hard <commit-hash>
Move the HEAD pointer and potentially alter the working directory/index.
git reset
is a more powerful command that rewrites history by moving the HEAD
pointer. Use it with caution, especially in shared repositories, as it can discard commits. The --soft
, --mixed
, and --hard
options control how your index and working directory are affected.
git reset --hard
is a destructive command. It will discard all uncommitted changes in your working directory and index, and move your branch pointer to the specified commit. Use it only when you are absolutely sure you want to lose all subsequent changes.