Inside Git: How it works and the role of the .git Folder

I’ve explored basic Git commands in my last blog. After learning those commands, I wonder how Git actually works internally?

Can I build my own Git? What do those commands do in the background? How are they actually making it look so simple to save the version history of our code?

In this blog, I’ll share my knowledge, which I've gained from watching videos and reading numerous articles published by highly skilled developers. They really helped me understand what is happening behind the scenes and how not to scare with the .git folder.

How Git Works Internally

Git is the de facto standard, but what makes git, the Git?

Git stores a snapshot of the file at that moment. Every time a developer adds something for staging or commits, Git takes a picture of that data and stores it as a reference to that snapshot. Git thinks of data like a stream of snapshots.

But, where does it store those snapshots and how? To understand this, let’s take an example: Create a folder named my-project and open this folder in any IDE (like VS Code) and run git init command in the terminal.

This command will create a .git folder in that project.

.git folder

Understanding the .git Folder

The .git folder is where magic happens. It provides features to save our project even without an internet connection, from creating a different branch for adding new features without disturbing the main branch, to checking the commit history. All of these things are saved inside this folder.

The .git folder is the heart of the Git repository; without the .git folder, our project is just a normal directory of files.

Okay! I got it, why git exists. But how did I get these many files and folders inside the .git directory just by one command? Actually git init initialized git, and it includes all the subfolders and files.

Inside .git Folder

Let’s see what role these files and folders play in version control.

hooks

The hooks, a directory that contains script files. We can customize these files accordingly, like: Don’t commit anything if the message does not have “add” in it. Similarly, we can write a script for any other action like pre-commit, post-commit, pre-merge commit, etc.

info

This directory mostly has only one file exclude , which is almost like a personal .gitignore file where I can tell what not to save from my code. This acts like a rule book that won’t be shared with other collaborators.

logs

This directory is very special as it stores all logs of the commit history of every branch, and has a HEAD file which has the log history of the current branch that the user is working on. Whenever we do git log , git search for log in this directory, and then shows the result. Every log has commit_id, the author’s name, date, and the ref of its parent (if any).

refs

This directory stores the commit hashes of the branch heads; git/refs/heads contains branch pointers. Each branch file stores the commit hash of the most recent commit on that branch.

~: refs/heads/master

index

An index is a file where git stores staging area information. This information helps git to know if there is any change or not.

HEAD

This file stores the reference to where the HEAD is pointing, so git knows where to look for the current commit. It’s like I know his phone number, but I don’t know where he is.

ref: refs/heads/main

If I go down this path, refs/heads/main It stores the hash of the latest commit.

config

This file stores repository-specific configuration, such as remotes and branch tracking. It’s more like how this repository behaves.

objects

This is the folder where git stores the actual data of our repository. Git is very clever when it comes to storing the data. Git has objects. All of them have different roles. Let’s learn more about this in the next section.

Git Objects

Git is a content-addressed object database. The beauty of git is how it plans to store the snapshots in a single folder. To accomplish this, Git actually has three types of objects: Blob, Tree, and Commit.

Blob Object

Blob means Binary Large Object; it stores file content. If two files(with the same file_name or different file_name) share the same content, then it doesn’t create another blob for it; instead, they both are going to share the same blob, i.e., it doesn’t care about the path or permission of the file. The only thing that matters is what’s inside that file.

Tree Object

The tree object represents a directory. It stores the filename, permissions, and path. The tree object is like the Big Boss of version control, as it points to other blobs as well as trees to make.

Commit Object

The commit object is also a hashed value; it has information like a snapshot, author name, author email, time-stamp, commit message, reference of parent, and root tree.

In short-

Blob Object   ----> stores file content
Tree Object   ----> stores folders
Commit Object ----> stores snapshot plus other meta-data

Relationship between commit, tree, blob

We can also check the type of object by using -t flag like this:

git cat-file -t <hashId>

// This will give an object type: blob,tree,commit

How Git Tracks Changes

The mechanism of tracking changes is really simple; Git tracks the diffs (differences). Git simply uses index file data and diff it from the information in HEAD, i.e., comparing new information with the old information.

What happens internally during git add and git commit

When a user runs git add :

1. First, it reads the file-content.
2. Create a blob object and calculate its hash.
3. Stores it in .git/objects and records the reference in the index file.

When a user runs git commit:

1. It reads the staging area.
2. Create a tree object and a commit object.
3. Links it to the previous commit and moves HEADto a new commit.

How Git uses hashes to ensure integrity

Everything in Git is hashed before it is stored. Git refers to data by its hash, not by filename. Because Git uses the hash of a file as its identity, Identical content is stored only once. To guarantee integrity, Git uses a cryptographic hash, i.e., SHA -1(in older versions) and SHA-256(New version). If there is a single bit of change, the resulting hash changes completely.