Git might seem like magic, but it's actually built on elegant principles. Understanding how Git works internally will deepen your knowledge and make you a more confident developer.

Understanding the .git Folder

When you initialize a Git repository with git init, Git creates a hidden .git folder in your project directory. This folder is the heart of your repository - it contains:

• objects/: Stores all the actual data (commits, trees, and blobs)

• refs/: Contains pointers to commits (branches and tags)

• HEAD: Points to the current branch you're on

• config: Project-specific configuration settings

• hooks/: Scripts that run at specific Git events

The .git folder is where Git maintains the complete history of your project.

Git Objects: Blob, Tree, Commit

Git uses three core types of objects to store information:

Blob (Binary Large Object)

A blob is the simplest object - it stores the content of a file. It doesn't store the filename, just the file content. Each blob has a unique SHA-1 hash based on its content. Two identical files will have the same blob hash.

Tree

A tree object represents a directory. It contains pointers to blobs (files) and other trees (subdirectories), along with their names and permissions. Trees are essentially snapshots of your directory structure.

Commit

A commit object represents a specific point in your project history. It contains:

• A pointer to the tree (representing the project state)

• Pointers to parent commit(s)

• Author information and timestamp

• A commit message

• A unique SHA-1 hash

How Git Tracks Changes

The Three-Stage Process

When you work with Git, your files move through three stages:

1. Working Directory - Your actual files

2. Staging Area - Files you've marked with git add

3. Repository - The actual stored commits

What Happens During git add

When you run git add <file>:

1. Git reads your file

2. Creates a blob object with the file's content

3. Stores the blob in .git/objects/

4. Updates the staging area (index) to point to this blob

What Happens During git commit

When you run git commit -m "message":

1. Git creates a tree object representing your staged files

2. Creates a commit object pointing to that tree

3. The commit also points to the previous commit (parent)

4. Stores both objects in .git/objects/

5. Updates the current branch reference to point to this new commit

How Git Uses Hashes to Ensure Integrity

Git uses SHA-1 hashing extensively:

• Content-Based Hashing: Every object's hash is calculated from its content. If even one byte changes, the hash changes completely.

• Integrity Check: This means Git can verify that nothing has been modified - if a commit hash is the same, everything in it is exactly as it was.

• Unique Identification: Every commit has a unique 40-character SHA-1 hash that identifies it permanently.

This cryptographic approach ensures you can trust your version history and detect any tampering or corruption.

Building a Mental Model

Think of Git like this:

• Blobs = Snapshots of individual files

• Trees = Snapshots of directories

• Commits = Snapshots of your entire project at a point in time, linked together in a chain

Each commit knows about its parent, creating a history you can traverse. When you switch branches, Git is simply changing what files are in your working directory based on the trees referenced by different commits.

Diagram: Understanding Git Internally

Commit A (parent: null)
  |
  └─> Tree (project structure)
       └─> Blob: file1.txt
       └─> Blob: file2.txt

Commit B (parent: Commit A)
  |
  └─> Tree (updated project structure)
       └─> Blob: file1.txt (same hash - unchanged)
       └─> Blob: file2.txt (new hash - changed)

When you commit, Git only stores new blobs for changed files. Unchanged files reference the same blob from the previous commit. This makes Git storage efficient.

Conclusion

Understanding Git's internal mechanisms - blobs, trees, commits, and hashes - gives you a mental model rather than just memorized commands. This deeper knowledge helps you debug problems, understand merge conflicts, and use Git more effectively in your projects.

Remember: Git is a graph of commits, and everything else is just different ways of navigating or manipulating this graph.