SHA-256 in Git: Why Every Commit, File, and Tree Has a Hash

Every Git commit has a hash — a 40-character (SHA-1) or 64-character (SHA-256) hex string that uniquely identifies that commit across every repository on Earth. This is not an arbitrary ID assigned by a database. It is a cryptographic hash computed from the actual content of the commit: the file changes, the author, the timestamp, the parent commit hash, and the commit message. Change any one of those things and the hash changes entirely. That property is what makes Git trustworthy as a version control system. This article explains how it works.

How Git Uses Hashing to Identify Everything

Git is, at its core, a content-addressable storage system. Every object Git stores — a file (blob), a directory snapshot (tree), a commit, a tag — is identified by the hash of its content. The hash is both the name and the integrity guarantee. When you run git commit, Git computes: 1. The hash of each changed file (blob object) 2. The hash of each affected directory tree (tree object) 3. The hash of the commit itself — which includes the tree hash, the parent commit hash, your name, your email, the timestamp, and the commit message The final commit hash is what appears in git log. It is deterministic: the same content with the same metadata always produces the same hash. It is also tamper-evident: if anyone modifies a single byte of a committed file or rewrites a commit message, the hash changes — and so does every subsequent commit in the chain, because each commit includes the hash of its parent. This chain structure is what makes rewriting Git history detectable. You cannot silently change an old commit — the hashes cascade forward through every descendant.

SHA-1 vs SHA-256: Why Git Is Switching

Git was built on SHA-1. Every commit hash you have seen in a repository — a 40-character hex string like `a3f2b1c...` — is a SHA-1 hash. SHA-1 has a known theoretical weakness: SHA-1 collisions are possible. In 2017, Google demonstrated a practical SHA-1 collision (the SHAttered attack) — two different PDF files with the same SHA-1 hash. For most Git workflows the practical risk is low, but the theoretical foundation of "same hash = same content" is broken. Git 2.29 (released 2020) introduced the SHA-256 object format. New repositories can be initialized with SHA-256 as the hash algorithm. SHA-256 commit hashes are 64 characters instead of 40. SHA-256 has no known practical collision attacks. The output space (2^256 possible hashes) makes a collision computationally infeasible with current technology. It is the same algorithm used for SSL/TLS certificates, cryptocurrency transaction verification, and file integrity checking worldwide. Most public repositories on GitHub and GitLab still use SHA-1 for backwards compatibility. The migration to SHA-256 is ongoing in the Git ecosystem but not yet universal. Sell Custom Apparel — We Handle Printing & Free Shipping

What Exactly Goes Into a Git Commit Hash

A Git commit hash is computed from a specific set of fields. If you have ever wondered why amending a commit or rebasing changes the hash, this is why. The commit object hashed by Git contains: - **tree:** the SHA hash of the root directory snapshot - **parent:** the SHA hash of the parent commit (or multiple parents for a merge) - **author:** name, email, and Unix timestamp - **committer:** name, email, and Unix timestamp (differs from author on rebased commits) - **commit message:** the full text Change any of these and the hash changes: - `git commit --amend` with a new message → new hash - `git rebase` → new hash (committer timestamp changes) - Changing a single character in any tracked file → new tree hash → new commit hash - Changing the parent (rebasing onto a different branch) → new hash This is why force-pushing after a rebase rewrites history — the commits have new hashes and diverge from the remote.

Generating a SHA-256 Hash to Understand the Algorithm

You can use the free hash generator to experiment with the core property that makes Git work: determinism and avalanche effect. **Determinism:** Hash the same string twice. The output is always identical. This is what allows Git to use a hash as a permanent object identifier — it is reproducible by anyone with the same content. **Avalanche effect:** Hash "hello" and then hash "hellp" (one character different). The two hashes share no recognizable pattern. A single character change produces a completely different 64-character output. This is what makes it impossible to tamper with a Git object and produce the same hash. To try it: 1. Go to wildandfreetools.com/generator-tools/hash-generator/ 2. Type "hello" — note the SHA-256 output 3. Change one character to "hellp" — the output is entirely different 4. Change it back to "hello" — the original hash returns exactly Git uses this same algorithm (SHA-1 currently, SHA-256 for new repos) to compute the hash of every file, tree, and commit. The avalanche effect is the property that makes tamper detection reliable.

Practical Ways the Commit Hash Protects Your Code

Understanding commit hashes is not just theoretical. Here is how they protect real workflows: **Verifying a deploy.** Your CI/CD pipeline deploys a specific commit SHA. If you want to confirm the running code matches what you intended to deploy, compare the commit hash in the pipeline to `git rev-parse HEAD` in the running container. Identical hash = identical code, provably. **Detecting tampering in a mirror or fork.** If a third-party mirror of a repository has been tampered with, the commit hashes will not match the original. GitHub displays commit SHAs — cross-referencing them against a trusted source detects modifications. **Pinning dependencies.** Package managers that support git-based dependencies often let you pin to a specific commit hash (`"dependency": "user/repo#a3f2b1c"`). This is stronger than pinning to a branch or tag, which can be force-pushed. A hash pin is immutable. **Audit trails.** Commit hashes in code review systems (GitHub PRs, Gerrit, GitLab MRs) are permanent references. Even after branch deletion, the hash references the exact state of code that was reviewed and approved.

Frequently Asked Questions

Can two different Git commits ever have the same hash?

In theory, yes — hash collisions are possible for any hash function. For SHA-1, a practical collision was demonstrated in 2017. For SHA-256, no practical collision is known and none is expected with current computing power. In practice, Git has additional protections: it checks for loose-object collisions and newer versions have SHAttered mitigation. But this is the reason Git is migrating from SHA-1 to SHA-256.

Why does git rebase change commit hashes?

Rebasing replays commits onto a new base. Even if the file changes are identical, the parent commit hash changes (you are attaching to a different point in history), and the committer timestamp changes (it is being re-applied now). Both fields are part of the commit object that gets hashed, so the output hash changes. This is why force-pushing after a rebase is necessary — the new commits have different hashes from the originals on the remote.

How long is a Git SHA-256 hash?

A full Git SHA-256 hash is 64 hexadecimal characters (256 bits). Git typically displays a shortened version — often 7-12 characters — which is enough to be unique within a typical repository. Git uses the full 64-character hash internally for storage and object lookup.

Can I use the online hash generator to compute Git object hashes?

You can use it to understand the SHA-256 algorithm, but Git does not hash raw file content directly. Git prepends a header to each object before hashing: for a blob it is "blob [size]\0[content]". The hash generator hashes the text you enter as-is, without the Git header prefix. The output will differ from git hash-object unless you manually include the exact header format in your input.