# 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.