This is the most important lesson in the module and, most likely, in the first third of the course. Everything Git does — committing, branching, merging, rewriting history — follows directly from how it stores information. Once you understand the data model you stop memorising commands and start deducing them: you know what is possible, what is dangerous, and why a command has the effect it has.

The central idea is surprisingly simple: Git is a hash-addressable content store, a key-value table where the key is the cryptographic fingerprint of the content and the value is the content itself. On that minimal foundation sit four object types and a handful of references, and that is the whole thing. In this lesson we open the box: we will look inside the objects with low-level commands, explore the .git folder and work out why the history is immutable and what "rewriting" it really means.

1. Hash-addressable content storage
2. The four object types
3. How they connect: the commit graph
4. SHA-1 and the move to SHA-256
5. What lives inside .git/
6. Hands-on exploration with plumbing commands
7. Immutability and rewriting history
8. Why this model explains everything

Git stores objects in a database where each object's key is the SHA hash of its own content.

A hash is the output of a cryptographic function that turns any amount of data into a fixed-length string. It has three properties Git takes advantage of:

1. Determinism. The same content always produces the same hash.
2. Diffusion. Changing a single bit produces a completely different hash.
3. Collision resistance. Finding two different contents with the same hash is infeasible.

The first property has two enormous consequences:

• Automatic deduplication. If styles.css does not change across twenty commits, its content is stored once. All twenty commits point at the same object.
• Integrity checking. To confirm an object has not been corrupted you recompute its hash and compare it against its key. If they differ, there is corruption.

The second property gives us another: any alteration of the content changes the identifier, so nothing can be modified silently.

Many version control systems store, for each version, the list of differences against the previous one. Reconstructing an old file means applying the chain of differences from the very beginning.

Git works the other way round: each commit records a complete snapshot of the project's state. Conceptually, it is as if it kept a photograph of every file at that moment.

The obvious objection is space: surely storing the entire project every time takes up an enormous amount? It does not, for two reasons:

1. Reuse by hash. Files that do not change are not stored again; the snapshot simply references them. If Ana only touches styles.css in a commit, new content is created for that file alone.
2. Packing. Periodically, Git compresses loose objects into packfiles, which do use delta compression between similar objects. But that is a storage optimisation invisible to the model: conceptually they are still snapshots.

Git's database contains exactly four object types. All of them are identified by their hash and all of them are immutable.

A blob (binary large object) stores the content of a file. Nothing else: not the name, not the permissions, not the path, not the date. Just the bytes.

This has an elegant consequence: if Ana copies styles.css to styles-backup.css without changing anything, Git stores no new content. There is one blob and two directory entries referencing it. The file name lives in the tree, not in the blob.

A tree represents a directory. It is a list of entries, each carrying four pieces of data: mode (permissions), type (blob or tree), hash and name.

Here is what the root tree of task-manager would look like in its first commit:

You will only ever meet a handful of modes in practice:

If the project had an img/ folder, the root tree would include an entry of type tree pointing at that folder's tree. Trees nest inside one another and build up the complete directory structure.

A commit is the object that gives the history its meaning. It contains:

• The hash of the root tree — that is, the complete snapshot of the project.
• The hash of its parent or parents: none if it is the first commit, one in the normal case, two or more if it is a merge.
• The author (whoever wrote the change) with their date.
• The committer (whoever recorded it) with their date. Usually they are the same person; they part company in scenarios such as a rebase or the application of someone else's patches.
• The message.

A real commit, shown raw, looks like this:

Notice what is not there: not a single change, no difference, no list of modified files. A commit does not store "what changed", it stores "how everything ended up". When Git shows you a commit's differences, it computes them on the spot by comparing its tree against its parent's. That detail explains why git show is a computation and not a simple read.

An annotated tag is an object that points at another object (almost always a commit) and adds metadata: the tag's name, who created it, when, a message and optionally a GPG signature.

It is the only one of the four types with a lightweight alternative: a lightweight tag creates no object, it is just a file in .git/refs/tags/ with a hash inside. That is why annotated tags are recommended for released versions: they leave an auditable trail. Module 5 develops the point.

The four object types link to one another by hash and form a directed acyclic graph (DAG). This diagram shows two consecutive commits of task-manager, with the second one modifying only app.js:

Three fundamental things to notice in the diagram:

1. The blobs for index.html, styles.css and README.md are shared between the two commits. Nothing has been duplicated. Only app.js has two distinct blobs, because its content changed.
2. The arrows point backwards. A commit knows its parent, but a parent does not know its children. That is why Git walks the history from the present into the past, and why git log starts with the most recent entry.
3. Two different root trees were created even though three of the four files are identical: the tree contains the hash of app.js, which changed, so the tree's content changed and so did its hash.

The references we met in the lesson Basic Git Terminology rest on this graph:

A branch is nothing more than a name pointing at a node of the graph. Committing means creating a new node and moving that name. That is all. Which is why branches are cheap, as we said up front in the lesson What Is Git?.

Git has historically used SHA-1, which produces 160-bit hashes written as 40 hexadecimal characters:

In practice, abbreviated forms of 7 to 12 characters (a3f5c9e) are used, enough to identify an object unambiguously in a normal repository. Git lengthens the abbreviation automatically if it detects a risk of ambiguity.

One important detail: the hash is not computed over the raw content, but over a header concatenated with the content. For a blob, what actually goes through SHA-1 is literally:

That \0 is a null separator byte. Thanks to the header, a blob and a tree with the same bytes produce different hashes.

In 2017, the SHAttered attack demonstrated a practical SHA-1 collision: two different PDF files with the same hash. This did not break Git overnight — exploiting it against a repository demands very specific conditions, and the graph's cross-references make it far harder — but it did set off the alarms.

The response came in two phases:

1. Collision detection. Since version 2.13, Git ships a hardened SHA-1 implementation (SHA-1 collision detection) that recognises the known attack's patterns and aborts if it finds them. That is a mitigation, not a solution.
2. Migration to SHA-256. Since version 2.29, Git supports repositories using 64-hex-character SHA-256 hashes. You choose at repository creation time and cannot change afterwards.

The transition is slow precisely because of interoperability: a SHA-256 repository cannot synchronise with a SHA-1 one, and the whole ecosystem — GitHub, GitLab, CI tooling — would have to support it simultaneously. A design for dual-hash repositories exists to allow the two to coexist, but it is not finished yet.

For this course and for your daily work: use SHA-1, which is what Git does by default. What matters is that you know the reasons behind the transition and understand that the data model does not depend on the particular algorithm.

A freshly created repository has this structure. Let us walk through it:

The pieces that genuinely matter:

Look at objects/a3/f5c9e2b1d4...: the first two characters of the hash name the directory and the remaining thirty-eight name the file. It is a simple optimisation: it avoids putting hundreds of thousands of files in a single directory, which badly degrades performance on many filesystems.

Every object file is zlib-compressed, so opening one in a text editor shows nothing but binary noise. To read them you need Git's own commands, which is exactly what we will do now.

Git separates its commands into two layers:

• Porcelain: the everyday user interface (git status, git commit, git log). Its output is designed for humans and may change between versions.
• Plumbing: low-level commands operating directly on the database (git hash-object, git cat-file, git rev-parse). Their output is stable and designed for scripts.

Day to day you will use the porcelain. Here we are going to use the plumbing precisely because it shows the model without decoration.

Output:

Breaking it down:

• echo "Task manager" sends that text to standard output.
• | pipes it into the next command.
• git hash-object --stdin reads standard input and computes the hash that content would have as a blob. It stores nothing: it only computes.

Check determinism for yourself: run the command twice, then change a single letter of the text.

The two hashes will be completely different, not similar. That is the diffusion property in action.

To store the object in the database, add -w (write):

The object now exists in .git/objects/. This command has to be run inside a repository.

This is the inverse command: given a hash, it shows what is inside.

The three options:

Applied to a commit, -p produces exactly the tree/parent/author/committer/message block we saw in section 2. Applied to a tree, it produces the list of entries. Applied to a blob, the file's content.

It translates any way of referring to an object into its full hash.

The reference syntax worth recognising from the start:

One very handy command for getting your bearings:

Putting the three commands together, this is how you navigate the model from the top down. The hashes in your repository will be different: replace them with whatever each command returns.

You have just walked by hand the same path Git walks internally every time you run any command: commit → tree → blob. If that walk feels clear, you have the mental model that holds up the rest of the course.

There is a convenient shortcut that combines a reference and a path:

The <reference>:<path> syntax resolves the tree and descends to the file in a single step.

We now have every piece we need to understand Git's most important property.

A commit's hash is computed over its content, and that content includes its parent's hash. Therefore:

If someone modified c1's message, its hash would change. c2 would then point at a hash that no longer exists, so c2 would have to change too, which would change its hash, which would force c3 to change, and so on to the end of the history.

Three guarantees come out of this:

1. The past cannot be altered unnoticed. Any change invalidates the entire chain that follows.
2. A commit's hash identifies the whole history leading up to it. If Ana and Bruno have the same hash at the tip of main, they have exactly the same history up to that point, byte for byte. That is a complete verification in a forty-character comparison.
3. Objects are never modified, only created. There is no operation in Git that edits an existing object.

This is the source of the "integrity" we listed among Git's virtues in lesson 01-01. It is not a promise: it is a mathematical property of the design.

If nothing can be modified, how is it possible to fix a commit message or reorder the history — things Git clearly allows?

The answer is that nothing is modified: new objects are created and the references are moved.

When you say "I'm going to fix the last commit's message", what happens is:

1. Git creates a new commit, with the same tree and the same parent, but with the corrected message. It has a different hash.
2. Git moves the main branch so that it points at the new commit.
3. The old commit still exists in the database. There is simply no longer any reference that reaches it.

Objects with no references pointing at them are called dangling (unreachable). They stay in the database and remain accessible by their hash or through the reflog — the record of every movement of every reference, which lives in .git/logs/ — until garbage collection (git gc) removes them, usually after a couple of weeks.

This has two capital implications:

• Almost nothing is truly lost. If you think you have destroyed committed work, the odds are it is still there. Module 9 devotes a whole lesson to getting it back.
• Rewriting shared history is dangerous. If Ana rewrites commits Bruno already has in his repository, Bruno's hashes stop matching Ana's: their histories diverge and reconciling them is painful. Hence the golden rule we will repeat in module 5:

Do not rewrite history you have already shared with others.

The operations that rewrite history — rebase, commit --amend, reset over published commits, filter-repo — are covered in modules 5, 8 and 9. What you need now is to understand why they differ from the rest: they create new objects and abandon the old ones, instead of adding at the end.

Let us close with the practical value of all this. These frequently asked questions answer themselves once you know the model:

Whenever some Git behaviour strikes you as odd in the coming modules, come back to this model and ask yourself: which objects are being created, and which references are being moved? The answer almost always turns up on its own.

• Believing Git stores differences. This is the most widespread conceptual error and it comes from experience with other systems. Git stores snapshots and computes differences when you ask for them. The differences you see in git log -p or in a code review are not stored anywhere.
• Thinking the blob holds the file name. It does not. The name lives in the tree. That is why Git does not record renames explicitly: it detects them by comparing contents between two trees.
• Poking around inside .git/ by hand. Exploring it with ls and reading HEAD or refs/heads/main is instructive and safe. Editing or deleting files in there is an efficient way to corrupt the repository. For everything else, there are commands.
• Trusting dangling objects to last forever. They survive the rewrite, but git gc removes them after a while (by default, 30 days for recent unreachable objects and 90 for the reflog). If you need to recover something, do it soon.
• Assuming an abbreviated hash is unique forever. Seven characters are enough in your repository today; in a repository with hundreds of thousands of commits they can turn ambiguous. When you record a hash in documentation, use the full form.
• Tip: run this experiment once. In any repository, follow the git cat-file -p HEAD → tree → blob walk from section 6. Ten minutes of manual exploration save months of confusion.
• Tip: when something goes wrong, think in references. The overwhelming majority of Git scares are not data loss but references pointing somewhere unexpected. The objects are almost always still there.

Ana creates a repository with index.html, styles.css, app.js and README.md, and makes a first commit. She then modifies only styles.css and makes a second commit. Finally, she copies styles.css to styles-old.css without changing the content and makes a third commit.

Answer:

1. How many distinct blob objects are in the database at the end? List them.
2. How many tree objects have been created in total?
3. How many commit objects are there?
4. Was any new blob created in the third commit? Why?

Using any Git repository you have to hand (if you do not have one yet, save this exercise for after module 2), run the complete exploration and note the results:

1. Get the hash of the current commit.
2. Show that commit raw and identify the hash of its tree and of its parent.
3. Show the tree and identify the hash of one of its files.
4. Show that file's content straight from the object database.
5. Check that the tree's type is tree and the file's is blob.
6. Find out that blob's size in bytes.

Ana has made three commits on main: c1, c2 and c3. She has pushed all three to the shared repository and Bruno already has them on his machine. Ana now notices a spelling mistake in c2's message and fixes it by rewriting the history.

Answer:

1. Which new objects are created and which are left dangling?
2. Does c1's hash change? What about c2's tree? Justify your answer.
3. What will Bruno see when he tries to synchronise?
4. Would it have been different if Ana had not pushed anything yet?

Solution to Exercise 1

1. Five blobs. One for each distinct content that has existed:

   • index.html (never changes): 1 blob
   • app.js (never changes): 1 blob
   • README.md (never changes): 1 blob
   • styles.css original version: 1 blob
   • styles.css modified version: 1 blob

   Total: 5. The content is the key, not the file.

2. Three trees. One per commit. The root tree changes in all three because the second changes the hash of styles.css and the third adds a new entry (styles-old.css). Since the project has no subdirectories, there is only a root tree.

3. Three commits, one per commit operation.

4. No new blob was created in the third commit. The content of styles-old.css is identical to that of styles.css, and Git stores content indexed by its hash: it already exists. The only new thing is a tree entry with a different name pointing at the same blob. This is the canonical example of content deduplication.

Solution to Exercise 2

Solution to Exercise 3

1. A new commit is created, call it c2', with the same tree and the same parent (c1) but a different message, and therefore a different hash. Since c3 pointed at c2, a c3' pointing at c2' has to be created as well. The original c2 and c3 are left dangling. The trees and the blobs do not change: they are reused whole, because the files' content was never touched.

2. c1 does not change: its hash depends on its own content and on its parent, and neither has been modified. c2's tree does not change either: the message is part of the commit object, not of the tree. It is a good reminder that the four object types are independent of one another and only linked by hash.

3. Bruno will see diverged histories. His local main points at c3, while the shared branch points at c3'. Git will tell him the branches have diverged and that each side has commits the other lacks. If he tries to integrate carelessly, he will end up with duplicated work: c2, c3, c2' and c3' in the same history. Fixing it requires Bruno to align his branch with the rewritten one, which module 9 covers.

4. Yes, it would have been completely different. If the commits only existed on Ana's machine, rewriting them would have no consequences at all: nobody else holds the old hashes, so no divergence is possible. This is exactly where the golden rule draws its line: rewriting local history is safe and advisable; rewriting shared history is dangerous.

Git is, at bottom, a key-value database where the key is the hash of the content. On that minimal idea stand four object types: the blob stores a file's content, the tree represents a directory and gives the blobs their names, the commit points at a root tree and at its parents while adding author, date and message, and the annotated tag marks a point in the history with metadata. Linked by hash, they form a directed acyclic graph on which branches and HEAD are nothing but names pointing at nodes.

That design leads directly to the properties that make Git what it is: deduplication (identical content is stored once), verifiable integrity (the hash betrays any corruption) and immutability (changing the past invalidates the entire chain that follows). And immutability gives "rewriting history" its exact meaning: nothing is modified, new objects are created and the old ones are abandoned, surviving as dangling objects until garbage collection. That is the basis of the golden rule — do not rewrite what you have already shared — and also of the good news that almost nothing is truly lost.

You have also seen the distinction between porcelain and plumbing commands, and you have walked the graph by hand with git rev-parse, git cat-file and git hash-object.

With the mental model in place, we return to the surface. Before Ana can create the task-manager repository she needs to adjust how Git behaves on her machine. In Configuring Git we will look at the configuration mechanism: the three levels of git config, where each file lives, which value wins when they conflict and how to keep separate profiles for work and for personal projects.