# Inside Git: How It Works and the Role of the .git Folder You've learned the essential Git commands like `git add` and `git commit`, but have you ever wondered what magic happens when you type them? Git isn't just a clever file copier; it's a sophisticated content tracker. Understanding Git's internal mechanics will transform your understanding from simply *using* Git to truly *mastering* it. Let's dive into the `.git` folder and explore the core components that make version control possible. ### Understanding the `.git` Folder: The Heart of Your Repository When you run `git init` in a directory, Git creates a hidden `.git` folder. This isn't just some metadata; it's the **entire Git repository**. It contains every piece of information Git needs to track your project's history, perform operations, and maintain its integrity. Without this folder, your project is just a regular directory of files. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769776481639/84addab3-eea8-4442-bcb8-0bbc6021275e.png align="center") Inside `.git`, you'll find several crucial subdirectories and files: * `objects/`: This is where Git stores all your content—your files, directories, and commit history—in a highly efficient and unique format. * `refs/`: Contains pointers (references) to commits, such as branches (`heads`) and tags. * `HEAD`: A special pointer that indicates which branch you are currently on. * `index`: Also known as the "staging area," this file records the content of your working directory that will go into the next commit. ### Git Objects: The Building Blocks of Your Project Git stores everything as one of four core "objects," each identified by a unique **SHA-1 hash** (a 40-character hexadecimal string). These hashes are crucial for Git's integrity; if even one bit of content changes, its hash changes, meaning Git knows it's a different object. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769776460100/9187c874-3654-4ea8-88b8-b8dc4510abc2.webp align="center") 1. **Blob (Binary Large OBject):** * **What it is:** A blob object simply stores the **content** of a file. It doesn't contain the filename or any directory structure. If two files have identical content, Git stores only one blob and points to it twice. * **Analogy:** Think of it as the raw data of your text file, image, or any other file. 2. **Tree:** * **What it is:** A tree object represents a directory. It contains a list of other tree objects (subdirectories) and blob objects (files), along with their filenames, permissions, and hashes. * **Analogy:** This is like a snapshot of a folder's contents, showing which files are inside and which subfolders exist. 3. **Commit:** * **What it is:** A commit object holds metadata about a specific point in your project's history. It includes: * A pointer to the top-level **tree** object for that commit (the entire project state). * Pointers to its **parent commit(s)** (showing its history). * Author and committer information. * Timestamp. * The commit message. * **Analogy:** A commit is the complete "snapshot" of your project at a moment in time, along with who took the picture and why. ### How Git Tracks Changes: `git add` and `git commit` Internally Let's trace the journey of your code when you use the two most common Git commands: ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769776630451/5bbf0763-a66a-42d7-87db-3b65881d52da.png align="center") #### 1\. `git add `: Preparing Your Snapshot When you run `git add index.html`: 1. Git takes the current content of `index.html`. 2. It calculates a **SHA-1 hash** for this content. 3. If a blob object with this content/hash doesn't already exist, Git compresses the content and stores it as a **blob object** in the `.git/objects/` directory. 4. Git updates the **staging area** (the `index` file in `.git`) to record that `index.html` (with its specific blob hash) is ready for the next commit. #### 2\. `git commit -m "My commit message"`: Saving Your History When you run `git commit`: 1. Git looks at the **staging area** (`.git/index`) to see which file contents (blob hashes) are prepared. 2. It then constructs **tree objects**: * It creates a tree object for each subdirectory, linking to their respective blobs and subtrees. * Finally, it creates a top-level tree object that represents the entire project's directory structure and file contents as they are in the staging area. All these tree objects are stored in `.git/objects/`. 3. Git creates a **commit object**: * It points to the top-level tree object. * It records the previous commit's hash as its parent. * It adds your author, timestamp, and commit message. * This commit object is also stored in `.git/objects/`. 4. Finally, Git updates the branch pointer (e.g., `HEAD` or `refs/heads/main`) to point to this new commit object. This meticulous process ensures that every commit is a complete, immutable snapshot of your project, linked to its parents to form a continuous history. ### The Power of Hashes: Integrity and Immutability Git's reliance on SHA-1 hashes for every object is fundamental to its robustness: * **Content Addressable:** Git doesn't store files by name; it stores them by their content's hash. This means if you have the hash, you can retrieve the exact content. * **Data Integrity:** Because the hash is derived from the content, any accidental or malicious alteration of a file or commit would immediately change its hash. Git would detect this discrepancy, guaranteeing the integrity of your history. * **Efficiency:** If you commit the same file content multiple times, Git only stores the blob once, saving space. By understanding these internal mechanisms, you gain a powerful mental model of how Git works, helping you troubleshoot issues, understand branching, and appreciate the genius behind this essential tool.