# How Git Works Internally

We all grind Data Structures and Algorithms(DSA) for interviews and then we switch to Development and think it’s a totally different world.

But here is the truth I found while digging into Git internals: **Git is literally just a Linked List.**

When we learn about Linked Lists in college, it feels theoretical. But every time you type `git commit`, you are adding a **Node** to the most famous Linked List in the world.

### The Behind The Scenes(BTS) Logic

If you look at the raw data inside the `.git` folder, the mapping is crazy accurate:

**The Node:** Your **Commit** is the Node. It holds your metadata or user data (author, message).

**The Pointer:** Every commit has a Parent Hash. This is literally the `prev` pointer in a Linked List. It points to the commit that came before it.

**The Head:** You know how we have a `head` pointer in DSA to track the start? In Git, **HEAD** is a pointer that always points to the last node you worked on.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768058661297/28cbab5b-7b1d-45f6-8f2f-5e676b27eead.jpeg align="center")

### Secret Part: SHA-1 & Trees

This is where it gets cool. How does Git actually save your code inside that Node?

It uses **SHA-1 Hashing**.

Every time you save a file, Git takes the raw content, runs it through an algorithm, and spits out a 40-character unique ID (like `a1b2c3 . . .`).

* Git doesn't care about the filename here. It only cares about the **content**.
    
* If two files have the exact same code, they share the exact same Hash, Efficiency level: 100.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768058987830/5e61da56-b4ed-402e-b4ff-465e36f18d6c.jpeg align="center")

So how does it remember folder structures?

Enter the Tree Object.

Think of a Tree Object as a simple directory list. It maps your filenames to those SHA-1 hashes.

* `"index.html"` - &gt; points to Blob `e4f2 . . .`
    
* `"styles/"` - &gt; points to another Tree `89a1 . . .`
    

### How Changes Spread

When you make a new Commit (node), Git doesn't copy all your files.

1. It creates a new **Tree** representing the current state of your folder.
    
2. If you only changed one file, Git generates a new SHA-1 for that file.
    
3. The new Tree points to the **new** file hash, but keeps pointing to the **old** hashes for everything else that didn't change.
    

### The Conclusion

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768059571562/2f24b762-a02d-4128-b698-c605b44285c9.jpeg align="center")

Stop treating Git like magic. It’s just a database of nodes (Commits) pointing to maps (Trees) pointing to data (Blobs).

If you can reverse a Linked List in an interview, you already understand how Git history works. We are just traversing nodes, bro!
