Git is powerful but often feels mysterious. When you use Git commands, you interact with a complex system running behind the scenes. Understanding what actually happens when you commit code deepens your knowledge and makes Git less confusing. This guide explains how Git works internally and what the hidden .git folder does.

How Git Works Internally

Git is a version control system that tracks changes to files over time. Most importantly, Git is a content-addressable storage system. This means Git stores content and retrieves it based on the content itself.

When you create a file and commit it to Git, Git does not store the file name directly. Instead, Git calculates a hash (a unique fingerprint) of the file content. This hash is used as a unique identifier for that content. If the exact same content exists elsewhere, Git recognizes it immediately.

This design has powerful implications. Two files with identical content produce the same hash. If you rename a file without changing its content, Git still recognizes it is the same file. If content is duplicated across commits, Git stores it only once, saving storage space.

Git tracks content through commits. A commit is a snapshot of your project at a specific point in time. Each commit contains a reference to the previous commit, forming a chain. This chain is your project history. You can navigate backward through history by following the chain of commits.

Git uses cryptographic hashing (SHA-1) to ensure integrity. Every piece of data Git stores is hashed. If even one byte changes, the hash changes completely. This makes it impossible to alter history without Git detecting the change. If someone attempts to modify a commit, the hash changes, revealing the tampering.

Understanding the .git Folder

When you run git init in a project directory, Git creates a hidden .git folder. This folder is the entire repository. Everything Git does—tracking history, managing branches, storing commits—depends on what is inside .git.

The .git folder has a standard structure:

HEAD file: Points to the current branch. When you switch branches, this file is updated to point to the new branch. When you check out a specific commit directly, HEAD points to that commit instead of a branch.

config file: Stores repository configuration. Settings specific to this repository, like the remote URL (origin), are stored here. When you run git remote add origin URL, this information is saved in config.

refs directory: Contains references to commits. Subdirectories include:

• heads: Contains branch references. Each branch is a file containing the commit hash that branch points to.

• remotes: Contains remote branch references. Tracks what branches exist on remote repositories.

• tags: Contains tag references. Tags mark specific commits, usually for releases.

objects directory: Stores all Git objects (blobs, trees, commits, tags). This is where the actual content lives. Objects are organized in subdirectories named after the first two characters of their hash for efficient lookup.

index file: The staging area. When you run git add, Git writes information about your files to the index. The index tracks which files are staged for the next commit.

logs directory: Stores reference logs. Git records when branches and HEAD change. You can view this history with git reflog.

hooks directory: Contains scripts that run automatically at certain points in Git workflows. Hooks can run before commits, after pushes, etc.

The .git folder is self-contained. Your entire project history exists in this folder. You can clone this folder to another location and have a complete copy of the repository.

Git Objects: Blob, Tree, Commit

Git stores four types of objects. The first three are fundamental to understanding how Git works.

Blob Object

A blob is a file's content. When you add a file to Git, Git creates a blob object containing that file's data.

A blob contains only the file content. It does not contain the filename, file permissions, or any metadata. Two files with identical content create the same blob hash.

When you store a blob, Git calculates its hash based on the content. The hash becomes the blob's identifier. Later, when you need to retrieve that content, you use the hash.

Tree Object

A tree is a directory listing. It maps filenames to blob objects (files) and other tree objects (subdirectories).

A tree contains entries like:

• filename: hash of blob object

• directoryname: hash of another tree object

When you commit, Git creates a tree object representing your entire project structure at that moment. The tree maps all files and directories to their respective blob and tree objects.

If a file has not changed since the previous commit, its hash is the same. The tree references the same blob. Git does not duplicate the file content.

Commit Object

A commit ties everything together. A commit contains:

• The hash of the tree object (what the project looks like)

• The hash of the parent commit (the previous commit)

• Author name and email

• Committer name and email

• Commit timestamp

• Commit message

The commit hash is calculated from all this information. If any detail changes, the hash changes.

Commits form a linked list. Each commit points to its parent. By following parent pointers, you can traverse the entire history.

Tag Object

A tag marks a specific commit, usually for releases. A tag contains the commit it marks, the tag name, and optionally a message. Annotated tags are objects stored in the objects directory. Lightweight tags are simple references in refs/tags.

How Git Tracks Changes

Understanding how Git tracks changes reveals the elegance of its design.

When you run git add:

Git examines each file you are adding. Git calculates the hash of each file's content and creates blob objects in the objects directory.

Git updates the index (staging area). The index now contains references to the blob hashes of the files you added.

At this point, the blobs exist in the objects directory, but they are not yet part of a commit. The index tracks what will be included in the next commit.

When you run git commit:

Git reads the index to see what files are staged.

Git creates a tree object that represents the current directory structure, mapping filenames to blob hashes (for files) and tree hashes (for directories).

Git creates a commit object that contains the tree hash, parent commit hash, author info, and your commit message. The commit hash is calculated from all this information.

Git updates the current branch reference to point to the new commit hash. When you are on main, the file .git/refs/heads/main is updated to contain the new commit hash.

How Git Computes Differences:

Git does not store differences between commits (deltas). Instead, Git stores complete snapshots.

To see what changed between two commits, Git compares their tree objects. Git looks at what files exist in each tree and what blob hashes they reference. If a file has a different blob hash, the content changed. If a filename is missing in one tree, the file was deleted.

This snapshot approach seems wasteful, but it is actually efficient. If a file is unchanged, it references the same blob. The blob is stored only once. Multiple commits can reference the same blob.

Ensuring Integrity:

Every object is identified by its hash. If you change even one byte of an object, the hash changes. This makes it impossible to secretly modify history.

If someone attempts to change a commit, the commit hash changes. The parent pointer in the next commit no longer matches. The entire chain is broken, revealing the tampering.

The Mental Model

Think of Git as a filing system. Each file is stored in a cabinet (objects directory). Each file is labeled with a unique code (the hash).

When you create a folder structure (tree), you document what files are in each folder and reference them by their code.

When you create a snapshot (commit), you record what the folder structure looks like at that moment and note the previous snapshot.

When you make a new snapshot, files that have not changed are referenced by their old code. New files get new codes. The new snapshot documents the changes.

By following the chain of snapshots backward, you can see your project's entire history.

Practical Example

Consider a simple workflow:

You create a file hello.txt with content "Hello":

• Git creates blob hash abc123

• You run git add hello.txt

• Index now references abc123 for hello.txt

You run git commit -m "Add hello file":

• Git creates tree object def456 that maps hello.txt to abc123

• Git creates commit object ghi789 that references tree def456 and has no parent

• .git/refs/heads/main is updated to ghi789

You modify hello.txt to "Hello World":

• Git creates new blob hash jkl012

• You run git add hello.txt

• Index now references jkl012 for hello.txt

You run git commit -m "Update hello":

• Git creates tree object mno345 that maps hello.txt to jkl012

• Git creates commit object pqr678 that references tree mno345 and parent ghi789

• .git/refs/heads/main is updated to pqr678

Now your history is a chain: ghi789 → pqr678. Both commits reference blob abc123 for the first file, but the second commit references jkl012. Storage is efficient because the first version is stored once.

Building Your Mental Model

Rather than memorizing Git commands, understanding Git's internal model makes Git intuitive.

Commits are snapshots, not changes. Each commit is a complete picture of your project at that moment.

Hashes identify content. The same content always produces the same hash. Different content produces different hashes.

Branches are pointers. A branch is simply a file containing a commit hash. Switching branches changes which commit you are on.

The index is staging. Before committing, you add files to the index. The index determines what will be in the next commit.

History is a chain. Commits point to parent commits, forming a linked list. Traversing the chain shows your history.

Hashing ensures integrity. Changing history requires changing hashes, which breaks the chain.

Understanding these concepts makes Git commands make sense. You are not memorizing arbitrary commands. You are performing specific operations on Git's internal structures.

Conclusion

Git's internal design is elegant and powerful. The .git folder contains your entire project history. Git objects (blobs, trees, commits) represent files, directories, and snapshots. Hashes identify content and ensure integrity.

When you run Git commands, you are manipulating these structures. Understanding what happens internally transforms Git from a mysterious tool into a logical system.

Key takeaways:

• The .git folder contains the entire repository

• Git objects include blobs (file content), trees (directory structure), and commits (snapshots)

• Commits are linked in a chain, forming history

• Hashes ensure data integrity and enable efficient storage

• Branches are simple pointers to commits

• Understanding Git internally is more valuable than memorizing commands

As you continue using Git, refer back to this mental model. When something confuses you, thinking about the underlying structures often clarifies what Git is doing.

Quick Reference