Git Logo

The identity of a Git commit explained

Kathryn Prestridge portrait

Kathryn Prestridge

15 November 2021 · 5 min read

A git commit is a snapshot of the repo at a particular point in time. They're used to save and track changes in a codebase, and are the building blocks of Git. At a high level at least, at a more fundamental level everything in Git is stored as an Object. Learning how commits work is fundamental to understanding how to take advantage of Git's full potential.

What is in a Git commit?

A Git commit object contains all the metadata of the commit. This includes the date, author, committer, the commit message, as well as the directory tree object hash, and parent commit hash(es).

To see the contents of the most recent commit and it's metadata on the current working branch, run git show --pretty=raw. It'll look something like this:

commit 4a07d916c1802d606a41e00b52e2068f6510ded6
tree 7ed44fc18fc76c66631ac3d4169107b1a48f9c58
parent a08bc7c445e17faad93000089aef41c71f129ade
author Jane Smith <> 1636455211 +1100
committer Jane Smith <> 1636455211 +1100

example commit

diff --git a/ b/
new file mode 100644
index 0000000..e69de29

<...the rest of the diff...>

You can see all the metadata we mentioned above. The author, date and commit message are obvious but the commit, tree and parent hashes are worth explaining in more detail.

The hash of a commit's parent commit acts as a pointer linking the all commits together. A commit can have multiple parent commits if a merge of one or more branches has been made.

The tree object referenced in the above commit contains the directory listing for the commit. This is made up of other branching Tree objects (sub-directories) and Blob objects (Binary large object containing the contents of the file). You can read more about Tree and Blob objects here.

What if I amend a commit?

Git commits are immutable. If you amend a commit and make changes, Git will create a completely new commit and a new commit identifier. It doesn't matter what metadata you change, the identifier will change. The old commit with it's original identifier still exists, and although it may not be visible we'll show you how to find it later on in this article.

Commits don't reference any of their children, so any changes to the commit's children won't alter the parent. Any changes to a parent commit however, will result in a new commit identifier for each of its children. This will be important to remember when we introduce Git rebase.

How do hash functions work?

A hash function is an algorithm that takes in data and returns a unique value. The most important features of a hash function are:

  • A hash function will always produce the same output for a given input
  • Any small change in the input data will produce a completely different output
  • The hash function is not reversible.

The unique 40-character identifiers of a Git commit are SHA-1 hashes. For more details, check out how hashing works and specifically SHA-1.

Small changes in input change the output a lot

Let's test this in our terminal:

$ echo -n "abcd" | openssl sha1

$ echo -n "abcd" | openssl sha1

The input "abcd" will return a hash of 81fe8bfe87576c3ecb22426f8e57847382917acf regardless of how many times it is run, or what system it is run on. If you change the text, even slightly, the returned hash will be wildly different. In the following cases we only change the input "abcd" by 1 single bit. Notice how different the resulting hash is?

$ echo -n "abcd" | openssl sha1

$ echo -n "bbcd" | openssl sha1

$ echo -n "abce" | openssl sha1

This means that if one change is made to a file, directory or the commit's metadata, no matter how small that change is, you will receive an entirely new (and very different) hash identifier.

Hash functions are irreversible

Hash functions are irreversible, so there is no practical way to find the contents that made the hash identifier. If this was possible it would break the cryptographic security of git. It is very unlikely but possible for a SHA-1 collision to occur, where different contents produce the same identifier.

Two objects colliding accidentally is exceedingly unlikely. If you had five million programmers each generating one commit per second, your chances of generating a single accidental collision before the Sun turns into a red giant and engulfs the Earth is about 50%.

However unlikely, it could be used as part of a collision attack. In 2017 the first SHA-1 collision was detected on GitHub, which is an interesting read. TL;DR - Git is not likely to be exploited in this way anytime soon, for reasons explained in the article.

Everything you commit to git is safe

Remember that Git commits are immutable. Git never really deletes anything that's been committed, unless you explicitly delete it. Even when performing operations such as rebasing or commit amending that modify commits. When we change a commit in this way, they are not actually deleted, a new commit is made and the old commit continues to be stored by Git even though it may not be visible through ordinary commands.

When a commit has nothing referencing it (a branch for example), it becomes invisible (to commands like git log). Git hides these from you because otherwise it would very hard to navigate around the mess of old commits. However the old commits still exist.

It's important to remember that you can always reference any commit by its SHA-1 hash. Remembering 40 character hashes is probably beyond the capabilities of most mortals, so one very handy way that we can find these old, invisible commits is in the reflog.

Finding invisible commits with git reflog

References (or "refs") can be thought of as named pointers to commits. Reference logs, or "ref logs" represent the history of every commit that git has ever pointed to. Any time the the tip of branches are changed it's recorded in the reflog. This could be through switching branches, merges, or even a rebase or amendment. This means that if you accidentally "lose" some data, there's a very good chance it is in the reflog, and you can retrieve it from there.

git reflog will show the reflog for the current working directory. By default, git reflog will output the reflog of the HEAD ref. You can get a complete reflog of all refs by executing git reflog show --all.


A Git commit contains all of the commit metadata and a snapshot of the repo at that point in time. The unique 40 character hash that represents the commit allows Git to track your commits and changes to the repo over time. They cannot be reverse engineered to see their contents.

When a commit is modified with git commit --amend or git rebase, it is not deleted, only replaced with a new commit with a new identity. We can always retrieve commits that are no longer visible via the reflog. Knowing the hash of the commit will make it easy to undo almost any git command with git reset --hard.

Understanding Git fundamentals and what's happening behind the curtain of Git will quickly increase your confidence and abilities, allowing you to take full advantage of Git and its tools.

Stay tuned as we'll be publishing a series of articles about understanding Git fundamentals and improving your Git Fu.

Kathryn Prestridge portrait


Kathryn Prestridge

I am a highly motivated developer, who loves continuously learning and combining my creativity and problem-solving skills to deliver exciting solutions. When I am not at my keyboard you will find me playing tabletop games or exploring new places with my dog, Tess.

More articles

Ash Framework


Announcing Ash 3.0

James Harton profile picture

James Harton

8 May 2024 – 2 min read

Precision machine tooling fuelled the industrial revolution


From Iron to Algorithms: How development frameworks are transforming software engineering

Ben Melbourne profile picture

Ben Melbourne

3 May 2024 – 3 min read

Want to read more?

The latest news, articles, and resources, sent to your inbox occasionally.