When you run a command:
git init
Git creates a hidden folder:
.git/

This folder is the entire version control system for your project. Your project files are just working data. The .git folder contains:

• History: The complete record of all changes made to project over time (every commits).

• Branches: These are mainly movable pointers to commits. It let us work on different version of projects in parallel.

• Metadata: Git stores extra information about the project, like author, name, email, commit time, config settings and messages.

Object Database: The storage system inside .git/objects where Git saves all blobs, trees, and commits using hashes.

High-level structure of .git

├── HEAD  
├── config  
├── index  
├── objects/  
│   ├── ab/  
│   └── f3/  
├── refs/  
│   ├── heads/  
│   └── tags/

There are 6 separate files/folder in the .git folder. Each file or folder has their own task to perform to make Git work efficiently.

Git Objects: Blob, Tree, Commit (The DNA of Git).

Everything in Git is stored as an Object. There are three main types of Objects:

1. Blob (File Content): A Blob stores the content of a file nots its name. For example we have a file index.html.
   It will store the content: Hello World
   The content becomes a blob with hash like:
   3b18e512dba79e4c8300dd08aeb37f8e728b8dad

if two files have identical content - they share the same blob.

2. Tree (Folder Structure): A tree object represents a directory. It stores.

   • File Names

   • Subfolders

   • Which blob belongs to which name

Example tree:

├── index.html (blob A)  
├── app.js (blob B)   
└── src/   
        └── utils.js (blob C)

3. Commit: A commit is a saved snapshot of your project, along with details like message, author, and a link to previous commit.

This Below diagram is a Gits Actual Data Model.

Commit
│
└── Tree
      ├── Blob (index.html)
      ├── Blob (app.js)
      └── Tree (src/)
            └── Blob (utils.js)

How Git Track Changes.

Git has three layers: Working Directory → Staging Area → Repository

1. Working Directory: In this normally files are stored.

2. Staging area (.git/index): A temporary area where Git prepares the next commit.

3. Repository (.git/objects): The permanent object database.

Git Command Internals.

Lets dive into the two important Git Commands git add and git commit -m.

What really happens during git add

When you run a git command: git add file.txt

Step by Step(internally):

1. Git reads the file content: Git opens file.txt and read its exact content(not the file name).

2. Git creates a hash of content: It generates a Hash code based on the content. This hash becomes the unique ID of that version of the file.

3. Git creates a blob object: Git stores that content as a blob object inside: .git/objects/

4. Git updates the Staging area (index): Git updates the .git/index file.

git add = convert file → blob → store it → prepare task for commit.

What really happens during git commit

Lets decode when you write a command: git commit -m “My message”

Step by Step(internally):

1. Git Reads the Staging area: it does not look the working directory it reads only from .git/index (staging area).

staged task = will be committed.
not staged = will be ignored

2. Tree Objects: Using the staged files, Git built a tree objects.

   This tree represents:

   • Folder Structure

   • File names

   • Which blob belongs to which file

    Tree
    ├── index.html → blob a1b2
    ├── app.js     → blob c3d4
    └── src/
        └── utils.js → blob e5f6

3. Git creates a Commit object: Now Git creates a commit object that stores:

• Hash of the tree

• Parent commit hash

• Author + timestamp

• Commit message

commit
  → tree hash
  → parent hash
  → metadata

4. Git updates HEAD and branch pointer: Finally Git updates

• HEAD

• Current branch (like main)

This is why: The new commit becomes the latest version.

git commit converts the staged index into a tree object, wraps it into a commit object with metadata and parent reference, and updates HEAD to point to the new commit.

How Git uses Hash to ensure integrity

Git uses hashes as unique fingerprint for everything its stores: files, folder and commits
Whenever Git stores Something it:

1. Takes the content.

2. Run a hashing algorithm

3. Generate a unique hashing like: f3a1c9b2e7...

What it means:

• If content changes → hash changes

• If a file is modified → its blob hash changes.

• If a commit is altered → commit hash changes

So Git can confidently guarantee: What you committed yesterday is exactly the same today.
Hash = tamper-proof-id of content.

Commit 1 → Commit 2 → Commit 3 → Commit 4
                                ↑
                              HEAD

This article delves into the internal workings of Git, explaining how it manages version control through the hidden `.git/` folder. It covers the role of Git objects like blobs, trees, and commits in storing file contents and project snapshots. The guide further explores Git commands like `git add` and `git commit -m`, detailing their internal processes. It also highlights Git's use of hashes to ensure data integrity, emphasizing how changes in content lead to different hashes, thereby guaranteeing the authenticity of your version history.