Skip to main content

Command Palette

Search for a command to run...

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

Brief discussion about how git works and what actually .git folder does

Updated
3 min read
Inside Git: How It Works and the Role of the .git Folder

1. The .git Folder: The Real Repository

When you run git init, Git creates a hidden folder named .git. This folder is your repository. The rest of your files (your code) are just the "Working Directory"—a temporary checkout of what's stored inside .git.

If you delete this folder, you lose your project's history, branches, and versions. It is essentially a database.

Key items inside .git:

  • objects/: This is the heart of Git. It stores the actual content of your files and commits.

  • refs/: Stores pointers to commits (like branches and tags).

  • HEAD: A simple text file that tells Git which branch you are currently looking at.

  • index: A binary file acting as the "Staging Area." It tracks what you are planning to put in the next commit.

2. Git Objects: Blob, Tree, and Commit

Git isn't just a list of changes; it is a content-addressable filesystem. It stores data as "Objects." There are three main types you need to know to build your mental model.

A. Blob (Binary Large Object)

  • What it is: The raw content of a file.

  • What it misses: It does not store the filename, created date, or permissions. Just the data inside.

  • Analogy: A polaroid photo. It shows the image, but doesn't say "vacation.jpg" on the back.

  • Note: If two files in different folders have the exact same text, Git stores only ONE blob.

B. Tree

  • What it is: A directory listing.

  • What it does: It maps filenames to Blobs (or other Trees). It creates the folder structure.

  • Analogy: A folder or a table of contents that says, "index.html is at Blob ID a1b2...".

C. Commit

  • What it is: A wrapper that captures the state of the project at a specific time.

  • What it holds:

    • A pointer to a main Tree (the root folder of your project).

    • Metadata: Author, committer, timestamp, and message.

    • Parent: A pointer to the previous commit (this creates the history chain).

3. How Git Tracks Changes (The Process)

This is the internal flow when you run the commands you learned earlier.

Step 1: git add filename

When you add a file, Git performs two actions instantly:

  1. Compresses the file content and stores it as a Blob inside the .git/objects folder.

  2. Updates the Index (Staging Area) to say, "The file filename now points to this specific Blob ID."

Step 2: git commit

When you commit, Git performs a calculation:

  1. It creates a Tree object that represents the current list of files in the Staging Area.

  2. It creates a Commit object that points to that Tree.

  3. It updates the current branch (e.g., main) to point to this new Commit object.

4. The Magic of Hashes (SHA-1)

You may have noticed weird strings like a1b2c3d... in Git. These are SHA-1 Hashes.

  • Integrity: Git takes the content of a file (or commit) and calculates a unique 40-character ID.

  • Content-Addressable: If you change even a single comma in a file, the Hash changes completely.

  • Security: This makes it impossible to corrupt the history or alter code without Git noticing, because the IDs would no longer match the content.

Summary: The Mental Model

Don't think of Git as storing "changes" or "deltas" (like "line 10 changed from A to B"). Think of Git as a Snapshot Manager.

  1. Snapshot: Every commit is a complete snapshot of your entire project structure (Trees) and files (Blobs).

  2. Efficiency: To save space, if a file hasn't changed between commits, Git doesn't make a copy; it just points to the existing Blob.