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

## Introduction

Let me be honest when I first started using Git, I was just blindly following commands:

```bash
git init  
git add .  
git commit -m "First commit"
```

In this blog, I’ll break down what happens under the hood how Git stores your files, what lives inside the `.git` folder, and how Git tracks your changes using blobs, trees, and commits.

---

## 📁 What is the `.git` Folder?

The `.git` folder is created the moment you run:

```bash
git init
```

This hidden directory is where **Git stores all version control data**. Think of it as the **brain of Git**.

Without this folder, Git has no memory of your commits, branches, or file history.

---

## `.git` Folder Structure

![.git folder](https://cdn.hashnode.com/res/hashnode/image/upload/v1767198958660/ead76461-cedc-40d4-9b10-5ad16016f182.webp align="center")

**Key Parts**:

* `HEAD`: Points to your current branch
    
* `objects/`: Contains all actual content, hashed and compressed
    
* `refs/heads/`: Contains your branch references
    

---

## Git Objects: Blob, Tree, and Commit

Git stores data as objects. There are 3 main types:

### 1\. **Blob (Binary Large Object)**

* Stores the **content** of a file.
    
* Doesn’t care about filename, just the content.
    

**Example**:  
If you write `Hello World` in `file.txt`, Git saves that content as a blob and gives it a unique hash.

---

### 2\. **Tree**

* Represents **folders or directory structures**.
    
* Stores filenames and links them to blob hashes.
    

**Example**:  
A tree might say:

* `file.txt` → points to blob `abc123`
    
* `about/` → points to another tree
    

---

### 3\. **Commit**

* A **snapshot** of the entire project at a specific point in time.
    
* Stores:
    
    * A pointer to the tree
        
    * A commit message
        
    * Author info
        
    * A pointer to the **previous commit**
        

---

## Commit → Tree → Blob Structure

Visualize this like a linked chain:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1767198732320/d4bb396c-7f0e-4c59-9840-51dd0262896a.png align="center")

---

## How Git Tracks Changes

Unlike some version control systems that store *diffs*, Git stores **complete snapshots**.

When you commit, Git doesn’t say “this line changed” - it says:

> “Here’s the full state of the project right now, and here’s what changed compared to the previous commit.”

This is made possible by the **content-addressed** system using **SHA-1 hashes**.

---

## What Happens When You Run `git add`?

Let’s say you run:

```bash
git add index.html
```

Here’s what Git does internally:

1. Takes the **content** of `index.html`
    
2. Creates a **blob object** for it
    
3. Adds an entry to the **staging area** (aka **index**) to mark it for commit
    

**Note**: Git doesn’t care about file names at this point only content!

---

## What Happens When You Run `git commit`?

Let’s say you run:

```bash
git commit -m "Add homepage"
```

Git performs 3 actions:

1. Takes the files in the **staging area**
    
2. Creates a **tree object**
    
3. Creates a **commit object**, linking to:
    
    * the tree
        
    * the previous commit
        
    * the message and author
        
4. Updates the branch (like `main`) to point to this new commit
    

---

## Git Workflow (Add → Commit)

Here’s how the process flows:

![git workflow](https://cdn.hashnode.com/res/hashnode/image/upload/v1767198687465/56f34d7f-428d-4b00-921f-c3eae52420f7.png align="center")

---

## Git Hashes: The Backbone of Git

Everything Git stores is hashed using SHA-1.

For example, this:

```bash
git hash-object index.html
```

…might return:

```plaintext
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
```

This means Git is saving content by its hash not file name.

Why is this awesome?

* Ensures **data integrity**
    
* Detects even the tiniest changes
    
* Prevents duplication