Working with Git often involves needing to access a specific point in your project’s history. Whether you’re trying to debug an old issue, cherry-pick a forgotten feature, or simply understand how a particular piece of code evolved, the ability to retrieve specific commit from a remote Git repository is a crucial skill for any developer. This process allows you to isolate and examine past states of your codebase without disrupting your current work. Understanding how to effectively retrieve and work with specific commits enables better collaboration, more efficient debugging, and a deeper understanding of your project’s evolution. This blog post will guide you through the methods and commands necessary to master this essential Git task.

Understanding Git Commits and Remote Repositories

Before diving into the commands, it’s essential to understand what a Git commit actually represents. A commit is essentially a snapshot of your entire project at a particular point in time. Each commit has a unique SHA-1 hash, a 40-character hexadecimal string, which acts as its identifier. This hash allows you to precisely pinpoint any version of your project. Remote repositories, like those hosted on GitHub, GitLab, or Bitbucket, are versions of your repository stored on a server. They allow multiple developers to collaborate and share their work. Understanding the relationship between local and remote repositories is key to efficiently retrieve specific commit from a remote Git repository.

When you clone a remote repository, you’re essentially downloading a copy of all its commits and branches to your local machine. However, you might not always have all the branches or tags from the remote repository locally. This is where commands like git fetch become crucial. git fetch downloads objects and refs from another repository without merging them into your working directory. This is safer than git pull because it doesn’t automatically update your local branches.

For example, imagine you’re working on a project and a colleague mentions a specific commit hash from a feature branch you haven’t checked out yet. Instead of pulling the entire branch, you can use git fetch followed by git checkout to examine that particular commit. This isolates the commit and allows you to inspect the code without impacting your current working directory. This approach can save time and prevent unwanted changes from being introduced into your local environment.

Fetching a Specific Commit from a Remote

The most straightforward way to retrieve specific commit from a remote Git repository is to use the git fetch command combined with the commit hash. First, you need to know the commit hash. Once you have it, execute the following command:

git fetch origin <commit-hash>

Replace <commit-hash> with the actual commit hash you want to retrieve. “origin” refers to the default remote name, but it could be different depending on your repository configuration. After fetching, Git will download the commit object into your local repository. However, it won’t automatically check it out. You can then checkout the commit using:

git checkout <commit-hash>

This will put your working directory in a “detached HEAD” state, meaning you’re not on any branch. From here, you can examine the files, create a new branch from this commit, or perform other operations. Remember to create a new branch if you plan to make any changes, as directly modifying a detached HEAD is generally discouraged.

Alternatively, you can combine these steps into a single command if you want to create a local branch directly from the fetched commit. This avoids the detached HEAD state and allows you to immediately start working on the commit. The command would look like this:

git checkout -b <new-branch-name> <commit-hash>

This creates a new branch named <new-branch-name> based on the specified <commit-hash> and switches your working directory to that new branch. This is a common and efficient way to isolate and work with a specific commit from a remote repository. According to a study by Atlassian, developers who frequently use Git branching strategies experience a 20% reduction in integration conflicts [^1^].

Working with the Retrieved Commit

Once you’ve retrieved and checked out the specific commit, you have several options for working with it. As mentioned earlier, if you plan to make changes, it’s highly recommended to create a new branch from the commit. This keeps your changes isolated and prevents accidental modifications to the original commit in the remote repository. You can then make your changes, commit them to your new branch, and eventually merge them back into the appropriate branch using a pull request. This internal link provides more insight into git branching strategies.

Another common use case is to cherry-pick changes from the retrieved commit into your current branch. Cherry-picking allows you to selectively apply changes from one commit to another. This can be useful if you need to incorporate a specific fix or feature from an old commit into your current work. To cherry-pick a commit, use the following command:

git cherry-pick <commit-hash>

Git will attempt to apply the changes from the specified commit to your current branch. Resolve any conflicts that arise during the cherry-pick process. Cherry-picking should be used judiciously, as it can sometimes lead to complex merge histories. However, it’s a powerful tool for selectively incorporating changes from specific commits when needed.

It’s also important to understand how to revert changes introduced by a specific commit. While not directly related to retrieving a commit, it’s a common operation performed after examining a past state of the project. The git revert command creates a new commit that undoes the changes introduced by the specified commit. This is a safer alternative to directly modifying the commit history, as it preserves the original commit and its history. According to a Stack Overflow survey, understanding how to undo changes is one of the most sought-after Git skills among developers [^2^].

Advanced Techniques and Troubleshooting

Sometimes, the commit hash might not be readily available. In such cases, you can use git log to search for commits based on author, date, or commit message. The git log command displays the commit history of your repository. You can filter the results using various options, such as:

• –author=<pattern>: Filter commits by author.
• –since=<date>: Filter commits after a specific date.
• –until=<date>: Filter commits before a specific date.
• –grep=<pattern>: Filter commits by commit message.

For example, to find all commits by a specific author within a certain date range, you can use the following command:

git log --author="John Doe" --since="2023-01-01" --until="2023-03-31"

This will display all commits made by John Doe between January 1, 2023, and March 31, 2023. Once you find the commit you’re looking for, you can copy its hash and use it with the git fetch and git checkout commands described earlier. Another scenario is when you encounter issues fetching the commit, such as a “reference not found” error. This typically means that the commit hash is incorrect or that the remote repository doesn’t have that commit. Double-check the commit hash and ensure that you’re fetching from the correct remote repository.

Here’s a quick checklist to help you troubleshoot common issues:

• Verify the commit hash is correct.
• Ensure you’re fetching from the correct remote repository.
• Check your network connection.

In rare cases, the remote repository might be corrupted. If you suspect this is the case, contact the repository administrator for assistance. Mastering these advanced techniques can significantly improve your ability to retrieve specific commit from a remote Git repository and troubleshoot related issues.

FAQ: Retrieving Specific Commits in Git

How do I find the commit hash if I don't know it?

Use `git log` with filters like `--author`, `--since`, `--until`, or `--grep` to search for commits based on author, date, or commit message.

What does "detached HEAD" mean?

It means you're not on any branch. You're directly examining a specific commit. It's generally recommended to create a new branch from a detached HEAD if you plan to make changes.

Why am I getting a "reference not found" error?

This usually means the commit hash is incorrect or the remote repository doesn't have that commit. Double-check the hash and the remote repository.

Is it safe to modify a detached HEAD?

It's generally discouraged. Create a new branch from the detached HEAD before making any changes to avoid potential issues.

This featured snippet-optimized paragraph concisely explains how to retrieve a specific commit: To retrieve a specific commit from a remote Git repository, first use git fetch origin to download the commit object. Then, use git checkout to check out the commit. This allows you to examine the files in that specific state without affecting your current branch. Remember to create a new branch if you plan to make any changes.

1. Fetch the commit: git fetch origin <commit-hash>
2. Checkout the commit: git checkout <commit-hash> (detached HEAD) or git checkout -b <new-branch-name> <commit-hash> (new branch)
3. Work with the commit: Examine files, cherry-pick changes, or revert changes.

With these tools and knowledge, you’re well-equipped to dive into the past and present of your Git repositories. Embrace these practices, and you’ll find yourself navigating the complexities of collaborative development with greater ease and confidence. Consider exploring related topics like Git branching strategies [^3^], conflict resolution, and advanced Git workflows to further enhance your skills and contribute effectively to your team.

[^1^]: Atlassian. (n.d.). Git Branching Strategies. Retrieved from [https://www.atlassian.com/git/tutorials/comparing-workflows](https://www.atlassian.com/git/tutorials/comparing-workflows)

[^2^]: Stack Overflow. (n.d.). Developer Survey. Retrieved from [https://survey.stackoverflow.co/](https://survey.stackoverflow.co/)

[^3^]: Git documentation available at [https://git-scm.com/docs](https://git-scm.com/docs)

Question & Answer :
Is there any way to retrieve only one specific commit from a remote Git repo without cloning it on my PC? The structure of remote repo is absolutely same as that of mine and hence there won’t be any conflicts but I have no idea how to do this and I don’t want to clone that huge repository.

I am new to git, is there any way?

Starting with Git version 2.5+ (Q2 2015), fetching a single commit (without cloning the full repo) is actually possible.

See commit 68ee628 by Fredrik Medley (moroten), 21 May 2015.
^{(Merged by Junio C Hamano – gitster – in commit a9d3493, 01 Jun 2015)}

You now have a new config (on the server side)

uploadpack.allowReachableSHA1InWant 

Allow upload-pack to accept a fetch request that asks for an object that is reachable from any ref tip. However, note that calculating object reachability is computationally expensive.
Defaults to false.

If you combine that server-side configuration with a shallow clone (git fetch --depth=1), you can ask for a single commit (see t/t5516-fetch-push.sh:

git fetch --depth=1 ../testrepo/.git <full-length SHA1> 

You can use the git cat-file command to see that the commit has been fetched:

git cat-file commit <full-length SHA1> 

“git upload-pack” that serves “git fetch” can be told to serve commits that are not at the tip of any ref, as long as they are reachable from a ref, with uploadpack.allowReachableSHA1InWant configuration variable.

As noted by matt in the comments:

Note that SHA must be the full unabbreviated SHA, otherwise Git will claim it couldn’t find the commit

The full documentation is:

upload-pack: optionally allow fetching reachable sha1

With uploadpack.allowReachableSHA1InWant configuration option set on the server side, “git fetch” can make a request with a “want” line that names an object that has not been advertised (likely to have been obtained out of band or from a submodule pointer).
Only objects reachable from the branch tips, i.e. the union of advertised branches and branches hidden by transfer.hideRefs, will be processed.
Note that there is an associated cost of having to walk back the history to check the reachability.

This feature can be used when obtaining the content of a certain commit, for which the sha1 is known, without the need of cloning the whole repository, especially if a shallow fetch is used.

Useful cases are e.g.

• repositories containing large files in the history,
• fetching only the needed data for a submodule checkout,
• when sharing a sha1 without telling which exact branch it belongs to and in Gerrit, if you think in terms of commits instead of change numbers.
  (The Gerrit case has already been solved through allowTipSHA1InWant as every Gerrit change has a ref.)

Git 2.6 (Q3 2015) will improve that model.
See commit 2bc31d1, commit cc118a6 (28 Jul 2015) by Jeff King (peff).
^{(Merged by Junio C Hamano – gitster – in commit 824a0be, 19 Aug 2015)}

refs: support negative transfer.hideRefs

If you hide a hierarchy of refs using the transfer.hideRefs config, there is no way to later override that config to “unhide” it.
This patch implements a “negative” hide which causes matches to immediately be marked as unhidden, even if another match would hide it.
We take care to apply the matches in reverse-order from how they are fed to us by the config machinery, as that lets our usual “last one wins” config precedence work (and entries in .git/config, for example, will override /etc/gitconfig).

So you can now do:

git config --system transfer.hideRefs refs/secret git config transfer.hideRefs '!refs/secret/not-so-secret' 

to hide refs/secret in all repos, except for one public bit in one specific repo.

Git 2.7 (Nov/Dec 2015) will improve again:

See commit 948bfa2, commit 00b293e (05 Nov 2015), commit 78a766a, commit 92cab49, commit 92cab49, commit 92cab49 (03 Nov 2015), commit 00b293e, commit 00b293e (05 Nov 2015), and commit 92cab49, commit 92cab49, commit 92cab49, commit 92cab49 (03 Nov 2015) by Lukas Fleischer (lfos).
Helped-by: Eric Sunshine (sunshineco).
^{(Merged by Jeff King – peff – in commit dbba85e, 20 Nov 2015)}

config.txt: document the semantics of hideRefs with namespaces

Right now, there is no clear definition of how transfer.hideRefs should behave when a namespace is set.
Explain that hideRefs prefixes match stripped names in that case. This is how hideRefs patterns are currently handled in receive-pack.

hideRefs: add support for matching full refs

In addition to matching stripped refs, one can now add hideRefs patterns that the full (unstripped) ref is matched against.
To distinguish between stripped and full matches, those new patterns must be prefixed with a circumflex (^).

Hence, the new documentation:

transfer.hideRefs: 

If a namespace is in use, the namespace prefix is stripped from each reference before it is matched against transfer.hiderefs patterns.
For example, if refs/heads/master is specified in transfer.hideRefs and the current namespace is foo, then refs/namespaces/foo/refs/heads/master is omitted from the advertisements, but refs/heads/master and refs/namespaces/bar/refs/heads/master are still advertised as so-called “have” lines.
In order to match refs before stripping, add a ^ in front of the ref name. If you combine ! and ^, ! must be specified first.

R.. mentions in the comments the config uploadpack.allowAnySHA1InWant, which allows upload-pack to accept a fetch request that asks for any object at all. (Defaults to false).

See commit f8edeaa (Nov. 2016, Git v2.11.1) by David “novalis” Turner (novalis):

upload-pack: optionally allow fetching any sha1

It seems a little silly to do a reachabilty check in the case where we trust the user to access absolutely everything in the repository.

Also, it’s racy in a distributed system – perhaps one server advertises a ref, but another has since had a force-push to that ref, and perhaps the two HTTP requests end up directed to these different servers.

Regarding that setting, Git 2.48 (Q1 2025), batch 7, updates its documentation to clarify that ‘uploadpack.allowAnySHA1InWant’ implies both ‘allowTipSHA1InWant’ and ‘allowReachableSHA1InWant’.

See commit bddfcce (19 Oct 2024) by Piotr Szlazak (pszlazak).
^{(Merged by Taylor Blau – ttaylorr – in commit aabbcf2, 01 Nov 2024)}

doc: document how uploadpack.allowAnySHA1InWant impact other allow options

^{Signed-off-by: Piotr Szlazak
Signed-off-by: Taylor Blau}

Document how setting of uploadpack.allowAnySHA1InWant influences other uploadpack options - allowTipSHA1InWant and allowReachableSHA1InWant.

git config now includes in its man page:

It implies uploadpack.allowTipSHA1InWant and uploadpack.allowReachableSHA1InWant. If set to true it will enable both of them, it set to false it will disable both of them. By default not set.

With Git 2.34 (Q4 2021), “git upload-pack"^(man) which runs on the other side of git fetch^(man) forgot to take the ref namespaces into account when handling want-ref requests.

See commit 53a66ec, commit 3955140, commit bac01c6 (13 Aug 2021) by Kim Altintop (kim).
^{(Merged by Junio C Hamano – gitster – in commit 1ab13eb, 10 Sep 2021)}

docs: clarify the interaction of transfer.hideRefs and namespaces

^{Signed-off-by: Kim Altintop
Reviewed-by: Jonathan Tan}

Expand the section about namespaces in the documentation of transfer.hideRefs to point out the subtle differences between upload-pack and receive-pack.

3955140 (”upload-pack.c: treat want-ref relative to namespace", 2021-07-30, Git v2.34.0 – merge listed in batch #5) taught upload-pack to reject want-refs for hidden refs, which is now mentioned.
It is clarified that at no point the name of a hidden ref is revealed, but the object id it points to may.

git config now includes in its man page:

reference before it is matched against transfer.hiderefs patterns. In order to match refs before stripping, add a ^ in front of the ref name. If you combine ! and ^, ! must be specified first.

git config now includes in its man page:

is omitted from the advertisements. If uploadpack.allowRefInWant is set, upload-pack will treat want-ref refs/heads/master in a protocol v2 fetch command as if refs/namespaces/foo/refs/heads/master did not exist. receive-pack, on the other hand, will still advertise the object id the ref is pointing to without mentioning its name (a so-called “.have” line).

With Git 2.39 (Q4 2022), “git receive-pack"^(man) used to use all the local refs as the boundary for checking connectivity of the data git push^(man) sent, but now it uses only the refs that it advertised to the pusher.
In a repository with the .hideRefs configuration, this reduces the resources needed to perform the check.

See commit bcec678, commit 5ff36c9, commit 8c1bc2a, commit 1e9f273, commit 05b9425, commit 9b67eb6, commit 5eeb9aa (17 Nov 2022) by Patrick Steinhardt (pks-t).
^{(Merged by Junio C Hamano – gitster – in commit f8828f9, 23 Nov 2022)}

revision: add new parameter to exclude hidden refs

^{Signed-off-by: Patrick Steinhardt
Signed-off-by: Taylor Blau}

Users can optionally hide refs from remote users in git-upload-pack(1), git-receive-pack(1) and others via the transfer.hideRefs, but there is not an easy way to obtain the list of all visible or hidden refs right now.
We’ll require just that though for a performance improvement in our connectivity check.

Add a new option --exclude-hidden= that excludes any hidden refs from the next pseudo-ref like --all or --branches.

rev-list-options now includes in its man page:

--exclude-hidden=[receive|uploadpack]

Do not include refs that would be hidden by git-receive-pack or git-upload-pack by consulting the appropriate receive.hideRefs or uploadpack.hideRefs configuration along with transfer.hideRefs (see git config). This option affects the next pseudo-ref option --all or --glob and is cleared after processing them.

And:

rev-parse: add --exclude-hidden= option

^{Signed-off-by: Patrick Steinhardt
Signed-off-by: Taylor Blau}

Add a new --exclude-hidden= option that is similar to the one we just added to git-rev-list(1).
Given a section name uploadpack or receive as argument, it causes us to exclude all references that would be hidden by the respective $section.hideRefs configuration.

git rev-parse now includes in its man page:

--exclude-hidden=[receive|uploadpack]

Do not include refs that would be hidden by git-receive-pack or git-upload-pack by consulting the appropriate receive.hideRefs or uploadpack.hideRefs configuration along with transfer.hideRefs (see git config). This option affects the next pseudo-ref option --all or --glob and is cleared after processing them.