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

## **TL;DR**

> Git saves **full copies of project** (snapshots), not line-by-line changes.  
> Each version has a **unique ID (hash)** and is linked to the previous one.
> 
> The `.git` folder is **where Git stores everything** — files, history, branches, and what you’re currently working on.
> 
> Git Objects contains:
> 
> * **Blob** → file content
>     
> * **Tree** → folders and file names
>     
> * **Commit** → a saved version of the project + message + link to previous version
>     
> 
> Git tracks changes by creating **new objects for new content** and reusing unchanged ones, then linking them together in a new commit snapshot.

## How Git Works Internally

Have you ever wondered what actually happens when you type `git init`? A hidden folder named `.git` suddenly appears, and your project seems to gain a memory. From that moment on, Git starts tracking your work — but how?

Most developers learn Git as a list of commands to remember: `add`, `commit`, `push`, `pull`. While that works, it often makes Git feel like a magic box. In reality, Git is a **simple and logical system**. Once you understand what happens behind the scenes, Git becomes predictable, powerful, and much easier to control.

### Git: Behind The Scene

1. `git init` : Creates the Brain of Git
    

* When you run:
    

```bash
git init
```

* Git creates a hidden folder called `.git` inside **<mark>your project directory</mark>**.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768307012338/959e3431-c70f-4d54-8459-a53afa7cbec7.webp align="center")

This `.git` folder is the entire **Git repository**. It contains everything Git needs to function:

* **<mark>Your project’s history</mark>**
    
* **<mark>Information about tracked files</mark>**
    
* **<mark>Commits and branches</mark>**
    
* **<mark>The current state of your project</mark>**
    

Without this folder, Git cannot track anything.

---

## **Understanding the** `.git` **Folder**

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

The `.git` folder is the **brain of your Git repository**. It stores *everything* Git needs to track your project—history, branches, commits, and configuration. Every time you run a Git command, Git reads from or writes to this folder.

> ⚠️ **Warning: *Never modify or delete the*** `.git` ***folder, or Git won't be able to track changes properly, and*** your project **will immediately stop being a Git repository**. **It will just be a regular folder of files with no version history.**

---

### What’s Inside the `.git` Folder?

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768307515886/0d065137-6c76-4d3a-8af0-45e91e0555c0.png align="center")

Here are the key parts, explained simply:

| File / Folder | What It Does and Stores |
| --- | --- |
| `objects/` | Stores all Git data (files, folders, commits) |
| `refs/` | Stores pointers to branches and tags |
| `HEAD` | Tells Git which branch you’re on |
| `index` | The staging area |
| `config` | Repository-specific settings |

---

### Why the `.git` Folder Matters

* It gives Git **memory**
    
* It enables **time travel** through commits
    
* It makes branching fast and lightweight
    
* It keeps data safe using hashes
    

---

## Git Objects: Blob, Tree, Commit

Everything in Git is built from just three object types. These objects work together to represent a complete snapshot of your project at any point in time.

### **Blob (Binary Large Object)**

A **blob** stores the **content of a file**.

* It contains *only* the file data
    
* It does not include the filename or folder information
    

### **Tree**

A **tree** represents a **directory**.

* Stores filenames and folder structure
    
* Points to blobs (files) and other trees (subfolders)
    
* Records file permissions
    

Think of a tree as a folder where blobs exist as files.

### **Commit**

A **commit** connects everything together.

* Points to a root tree (the project snapshot)
    
* Stores the author, date, and message
    
* Links to one or more parent commits
    

A commit represents **one saved version** of your project.

---

### How They Work Together

Each commit points to a tree, which points to blobs and other trees. This structure allows Git to reuse unchanged data and stay fast.

```bash
Commit
 └── Tree (root folder)
     ├── file1.txt → Blob
     ├── file2.txt → Blob
```

---

## How Git Tracks Changes

Git tracks changes by **saving copies of your files** and connecting them together. It does not remember line-by-line changes. Instead:

1. It takes a snapshot
    
2. Stores references
    
3. Reuses unchanged objects
    

### Git Working Areas

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768309459072/5fd84519-b8c0-486d-9bdc-c2d57066e6d0.png align="center")

1. **Working Directory** is an area where you **actually work**.
    
2. The **staging area** is a **temporary holding place** for changes.
    
3. The **repository** is where **Git** stores all commits. This is Git’s **long-term memory**.
    

### What happens internally during `git add` and `git commit`

When you run:

```bash
git add file.txt
```

Git does:

1. Reads the file’s content
    
2. Creates a **blob object** from that content
    
3. Stores the blob in `.git/objects/`
    
4. Updates the **index** to point to this blob
    

At this point:

* The change is **staged**
    
* Nothing is committed yet
    
* History has not changed
    

> **Note:** Think of `git add` as **preparing a snapshot**, not saving it.

When you run:

```bash
git commit -m "message"
```

Git now turns the staged snapshot into history:

1. Git reads the index
    
2. Creates **tree objects** that represent folder structure
    
3. Creates a **commit object** that:
    
    * Points to the root tree
        
    * Stores the message, author, timestamp
        
    * Links to the previous commit (parent)
        
4. Moves the current branch pointer to this new commit
    

> **Note**: Your snapshot is now permanent.

---

## How Git Uses Hashes to Ensure Integrity

Git uses **hashes** to make sure your data is **safe, unchanged, and trustworthy**.

### What Is a Hash? (In Git Terms)

A **hash** is like a **fingerprint** for data.

* Git takes some content (a file, folder, or commit)
    
* Runs it through a math function (SHA-1 or SHA-256)
    
* Produces a **unique string** like:  
    `a1b2c3d4...`
    

> **Note**: 1. Same content = same hash  
> 2\. Changed content = completely different hash

### How Git Uses Hashes

**1\. Every Object Gets a Hash**

Git gives a hash to:

* Files (blobs)
    
* Folders (trees)
    
* Commits
    

The hash is used as the **name** and **ID** of that object.

**2\. Commits Are Linked by Hashes**

Each commit:

* Has its **own hash**
    
* Stores the **hash of its parent commit**
    

```bash
Commit C → hash of Commit B → hash of Commit A
```

If **any commit is changed**:

* Its hash changes
    
* Every commit after it breaks
    

---

## Building a Mental Model

Instead of memorizing Git commands, it’s more helpful to **visualize how Git organizes your work**.

* **Working Directory**  
    Your sandbox where you edit and experiment with files.
    
* **Staging Area (Index)**  
    A *draft* of your next snapshot. This is where you decide exactly what will be saved.
    
* **Object Store**  
    Git’s permanent library inside the `.git` folder, holding every version of every file ever saved.
    

When you create a commit, Git doesn’t store a list of line-by-line changes. Instead, it saves a **snapshot of your entire project** exactly as it looks at that moment.

Behind the scenes, Git stores file content as **blobs** and identifies them using **hashes**. If a file hasn’t changed between two commits, Git doesn’t save it again—it simply points both commits to the same existing blob. This smart reuse of data is what makes Git **fast, efficient, and reliable**.

---

## Keep Learning 🚀

> Now that you’ve explored how Git works under the hood, it’s time to put that knowledge into practice. Understanding the internals gives you confidence—but using Git regularly is how it truly clicks. Check out these guides to continue your journey:
> 
> ### [**Why Version Control Exists: The Pendrive Problem**](https://blog-git-need.hashnode.dev/)
> 
> Ever wondered *why* tools like Git were created in the first place? This post explains the real-world problems version control solves and why it’s essential for modern development.
> 
> ### [**Git for Beginners: Basic and Essential Commands**](https://blog-basic-git.hashnode.dev/)
> 
> Ready to start coding? This guide walks through the **must-know Git commands** every developer uses in their daily workflow, explained clearly and practically.
> 
> 🔗 **Connect with me:**  
> [**LinkedIn**](https://www.linkedin.com/in/rajharsh4618) | [**GitHub**](https://github.com/Harsh-Raj4618) | [**X (Twitter)**](https://x.com/Harsh_Raj4618)