Match a git commit hash
Match a git commit hash in its short or full form — 7 to 40 lowercase hex characters, the same range git itself accepts as an abbreviation.
Last updated
Matches
- fixed in a1b2c3d today
- revert 9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c3b2a1f0e please
- ordinary word deadbeef also matches
Doesn’t match
- ABCDEF1 is uppercase only
- too-short a1b2c3 stays put
Why it’s written this way
Git's short hashes are usually 7 characters and its full SHA-1 hashes are 40, so [0-9a-f]{7,40} covers the whole legitimate range in one bounded repetition, with \b on each side to avoid matching a slice out of a longer run of hex-looking characters.
Restricting the character class to lowercase 0-9a-f is deliberate: git normalizes hashes to lowercase, so requiring lowercase here rules out a class of false positives from uppercase hex tokens that are clearly something else.
Edge cases to know
- →Any ordinary lowercase hex word in the right length range matches, hash or not — 'deadbeef' is a real English-adjacent word to a git user and also a perfectly valid 8-character hex string, so it matches here with no way to tell the difference from context alone.
- →It is deliberately case-sensitive to lowercase only — a hash pasted or displayed in uppercase (some tools do this) will not match unless it's lowercased first.
- →It cannot distinguish a short hash that is ambiguous in a given repository (matches more than one commit) from one that uniquely identifies a commit — that check requires the actual git object database, not a regex.
Part by part
- \b
- Word boundaries at both ends, which stop the match beginning partway through a longer hexadecimal string.
- [0-9a-f]
- Lowercase hex only. Git writes object names in lowercase everywhere, so accepting uppercase would only add false positives.
- {7,40}
- Between seven and forty characters: seven is git's traditional abbreviated length and forty is a full SHA-1 object name.
Common mistakes
\b[0-9a-f]{40}\bRequiring the full length misses every abbreviated hash, which is what git itself prints in log output, branch listings and error messages — so it fails on the text people actually paste.
\b[0-9a-f]{7,40}\b\b[0-9a-f]{4,40}\bLowering the minimum to four turns ordinary words into matches: "deed", "face", "cafe" and "added" are all valid hex. Seven is low enough to catch real abbreviations and high enough to avoid English.
\b[0-9a-fA-F]{7,40}\bAccepting uppercase gains nothing, because git never emits it, and costs precision by matching uppercase hex from other sources such as Windows checksum output.
Questions
Will it match ordinary words?
Some, yes. Seven-letter strings drawn from a-f and digits are rare in prose but not impossible — "defaced" and "beefed" both qualify. Anchoring to the context you expect, such as after the word commit, removes most false positives.
How short can an abbreviated hash safely be?
Git picks a length that is currently unambiguous in your repository, starting around seven and growing as history does. An abbreviation that is unique today can collide later, which is why anything permanent should record the full name.
Does this work with SHA-256 repositories?
Only for the abbreviated forms. Git's SHA-256 object format uses sixty-four characters, so raise the upper bound to 64 if you work with those repositories — the lower bound stays sensible.
Can I tell a commit from a blob or tree hash?
Not from the string. All git object names are the same shape regardless of type, so only asking the repository — with git cat-file -t — will tell you what a given hash points at.