The Secret Life of git init: Inside the .git Folder

Hello Fellow Devs 👋,

Why do we do git init? Well, to initialize a Git repository, right? Yes, that’s correct — but let’s go a little deeper into what it actually does and why it is required.

If you’ve read my previous blog where I discussed the layers of Git, you might remember that the core layer of Git is called the persistence layer. This layer is responsible for saving and storing our content (code base). Without it, Git has nowhere to keep our project history.

So, what exactly happens when we run git init?

The .git Folder

When you type git init Git creates a folder called .git inside your project directory. Inside it, Git sets up a whole directory structure that it will use to track changes, manage versions, and perform all the cool operations we use every day.

Some of the key parts inside .git are:

• objects/ → where Git stores all your data as objects (commits, trees, and blobs).
• refs/ → contains references to branches and tags.
• HEAD → a file that points to your current branch.
• config → repository-specific settings.
• index → staging area file that keeps track of changes you’ve added.

The Objects Folder

Let’s talk about the objects/ folder because that’s where the magic happens.

This is the location where all your content is stored, and Git doesn’t just dump files here. Instead, Git uses the SHA-1 hashing algorithm to hash the content and then store it.

And here’s the important part: Git only cares about the content, not the filename.

• The actual content of a file is stored in a data block.
• Git then creates a hash of that content and uses it as a reference.
• Filenames, directory structure, and commits are stored as additional metadata, but the heart of it all is the content hash.

A Quick Example

To see how Git thinks, try this:

`echo "Hello Git" | git hash-object --stdin`

You’ll get an SHA-1 hash as output. That’s basically how Git stores data internally — it converts content into a hash and uses that hash as the identifier.

👉 Note:

• git hash-object is a plumbing command.
• The | (pipe) takes the output on the left (echo "Hello Git") and feeds it as input to the command on the right (git hash-object).
• The --stdin flag tells Git to read the content directly from standard input.

That will look something like:

Now here’s something interesting: the content isn’t stored yet. What you just saw is the hash Git would use if it were to save this data. To actually write it into Git’s database, you need to use the -w flag:

echo "Hello Git" | git hash-object --stdin -w

You’ll still get the same hash because the content hasn’t changed. But this time, Git writes it into the objects/ folder inside .git

We still get the same hash because the content is the same. If you check your .git/objects directory now, you’ll see a new folder:

Inside it, you’ll find a file (something like 4d...) that represents your content. That file isn’t the raw text "Hello Git" but a compressed object with metadata. Git always stores data this way — hashed, compressed, and referenced.

Final Takeaway

So next time you run git init, remember:

• You’re not just “starting a repo.”
• You’re asking Git to set up its database (the .git folder) where it can store and track everything about your project.
• Without this step, Git has nowhere to save your history.

In short: git init Lays the foundation for all version control magic that follows. 🚀

If you found this useful, give it a 👍 and follow along for the next part!