Inside Git: How It Works and the Role of the .git Folder

Source: Dev.to

Introduction

For many developers, Git feels like a magical incantation. We type git add . followed by git commit -m "fixed stuff", push to a remote server, and hope for the best. When it works, it’s fantastic; when it breaks, it can feel like trying to defuse a bomb while blindfolded.

Understanding what happens beneath the surface turns blind memorization into true mastery. Git isn’t just a list of commands; it’s a carefully designed system for managing information. By peeling back the layers, we can build a mental model of how Git actually “thinks.”

The .git Folder

The hidden heart of your repository is the .git folder. It is usually hidden in file explorers because manual changes can corrupt the repository.

• Working directory – everything outside .git; the sandbox where you edit files.
• .git folder – the database that stores every version of every file, the entire commit history, and all branches.

Important: Deleting the .git folder erases the entire project history, leaving only the current files you see on disk.

Key Sub‑directories and Files

Git functions as a key‑value store. The key is a 40‑character SHA‑1 hash generated from the content. Any change to the content produces a completely different hash, guaranteeing data integrity.

Git’s Data Model

Object Types

Git stores three main types of objects in objects/:

Blob

• Contains the raw content of a file.
• Does not store the file name or its location.
• Identical content in different files results in a single shared Blob.

Tree

• Represents a directory.
• Contains entries that point to Blobs (files) and other Trees (sub‑directories), together with their filenames.

Commit

• Ties everything together into a snapshot.
• Contains:
  • A pointer to the top‑level Tree (the project root at that moment).
  • Metadata: author, timestamp, and commit message.
  • A pointer to the parent Commit (the previous snapshot).

Understanding these objects clarifies the role of the staging area (also called the Index).

The Staging Area (Index)

The Index records which Blobs should be included in the next snapshot.

Adding a File (git add)

git add style.css

When you run git add:

1. Git compresses the file’s content into a Blob.
2. It computes the Blob’s SHA‑1 hash and stores the Blob in .git/objects/.
3. The Index is updated to map style.css to that Blob hash, indicating that the file should be part of the next commit.

Creating a Commit (git commit)

git commit -m "Added Styles"

When you run git commit:

1. Git creates a Tree object that reflects the current directory structure, using the Blob hashes recorded in the Index.
2. It creates a Commit object that points to this Tree and to the previous Commit.
3. The current branch reference (e.g., refs/heads/main) is moved to the new Commit’s hash.

---

By visualizing the flow from working directory → Blob → Tree → Commit, you can see exactly how Git records history and why operations like git add and git commit behave the way they do.