Write the requirement as a name, an at sign, and a git plus https URL, then end the URL with an at sign and the full 40 character commit hash. A branch name follows new pushes, and a tag can be recreated, but a commit hash names one exact snapshot of the code.
The syntax pip supports
pip's documentation gives the general form as the project name, an at sign, then the version control URL. For Git the supported schemes include git plus https and git plus ssh. It discourages the plain git, git plus git and git plus http schemes, because the Git protocol has no authentication and HTTP is not encrypted.
After the URL you can add an at sign and a Git reference. The documentation shows a branch, a tag, a full commit hash and a pull request reference as valid examples. It recommends a full hash over a partial one because pip can work more efficiently.
MyProject @ git+https://git.example.com/MyProject.git@da39a3ee5e6b4b0d3255bfef95601890afd80709
Why the reference you choose matters
| Reference | Fixed over time? |
|---|---|
| Branch such as main | No, moves with every push |
| Tag such as v1.0 | Usually, but a tag can be deleted and recreated |
| Full commit hash | Yes, it names one commit |
The pip page shows the syntax but does not make a claim about movement, so this table reflects how Git works in general rather than a pip guarantee.
Steps
- Find the commit you reviewed in the repository history.
- Copy the full hash, not an abbreviation.
- Put it in the requirement as shown above.
- Record in a comment why the project uses Git instead of a registry release.
- Revisit when a normal release appears.
Things a commit pin does not fix
Pinning the commit does not review the code. Also, the repository itself can disappear, move, or be taken over by someone else. Consider mirroring any Git dependency you cannot live without into a repository you control. Hash checking in pip needs a URL or a pinned version, so a Git dependency fits only when you pin it as above.
When a Git dependency is a warning sign
Most projects that depend on a Git URL do so because a fix is not yet released, or because the code is internal. Both are fine, but each deserves a note. A fix that is not released may be unreviewed, and an internal repository needs the same access controls as the rest of your source. If the dependency is third party and has been on a commit pin for months, ask whether a release now exists and whether the maintainer is still active.
Also watch how the code gets built. A Git install builds from source on your machine, so any build step in that repository runs during install.
Quick check
Is a tag safe enough to pin to?
It is better than a branch, but a commit hash is the exact option. Prefer the hash.
Can I use a short commit hash?
pip accepts it, but its documentation prefers a full hash for efficiency and clarity.
Safeguard's dependency scanning lists direct and transitive components in an SBOM, so Git sourced packages show up in the inventory. A free scan is open to try.
Sources
Last reviewed: 19 October 2026.
