Git init: Inside the .git Folder

Ishank Gupta — Mon, 08 Sep 2025 17:25:48 +0000

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!

How Git Works!?

Ishank Gupta — Tue, 02 Sep 2025 17:15:02 +0000

Hello Fellow Devs 👋,

Have you ever wondered how Git actually works under the hood? Most of us use just a handful of Git commands every day, but Git is far more powerful than git add, git commit, and git push.

To really understand Git, we need to look at its layers. Why? Because Git isn’t just a collection of commands — it’s a distributed version control system, written in C by Linus Torvalds (the creator of Linux). And like any well-designed software, Git has multiple layers working together.

Why Learn About Git’s Layers?

Most developers stay at the surface, using Git as a command-line tool to push and pull code. But behind the scenes, Git organizes, stores, and manages data in a very structured way.

By understanding these layers, you’ll not only know what happens when you type a command, but you’ll also be better prepared to solve tricky Git problems in real projects.

The Four Layers of Git

The persistence layer is what makes Git, well, Git. It stores all of your project’s history in a special hidden folder called .git inside your project directory. This includes:

Commits
Branches
Tags
Objects (blobs, trees, commits)

When you run:

git init

Git sets up this .git folder and initializes its internal file system. From this point on, every change you make can be tracked, committed, and versioned. That folder is your repository—the heart of Git.

Wrapping Up

Most developers see Git only as a set of commands, but under the hood, it’s a layered system. By starting with the persistence layer, we can appreciate how Git manages to track everything so reliably.

In the next post, we’ll uncover how Git uses hashing to uniquely identify everything you store. Don’t miss it 👀