You don’t know where your code history is actually stored? How git is tracking your history? Or how Git knows what changed?

In this blog i will discuss How git works internally and Role of .git folder.

Understanding the .git folder

When you run git init in a folder have you notices nothing changes in folder Thats because Git creates a hidden folder called .git.

Thid folder is the brain of your project. It contains everything - history, branches, config settings and actual file contens in a compressed format.

Try this: Go to your project terminal and run: ls -a

You will see .git. If you delete this folder, your project forgets everything and It becomes just a normal folder again, No History, No Versions.

Inside .git, the most important sub folder is objects/. Here all data is stored.

Git Objects

Git stores data in a very specific way using ‘Objects’. In simple language Git is a key - value store like Disctionay or HashMap.

There are three main types of Objects you must know :

A. Blob (Binay Large Object)

. This stores content of your file

. It stores only the data, not the filename.

. If You have two files with the exact same text, Git will store only one Blob.

B. Tree

. This represnets Your directories.

. A Tree object stores - List of filenames and Pointers to Blobs (files) or other Trees (sub-folders).

. It connects the content with filename.

C. Commits

1. This is the snaphsot you see in history

2. A Commit Object stores :

   • The Tree (the state of folders at that time).

   • Metadata (Author, Timestamp, Message).

   • Parrent Commit (The previous commit hash).

How Git Tracks Changes (Internel flow)

When you works on a project you usually run two commands git add and git commit. Let’s see what happens internally.

Step 1: git add.

When you run this, Git takes your file content and compresses into a Blob and saves it inside .git/objects.

It then updates the Staging Area (Index) to say “ Hey, this file is ready to be commited”.

Step 2: git commit -m “message”

1. Git creates a Tree Object representing your current folder structure.

2. It creates a Commit Object that points to this tree.

3. It links this new commit to it’s parent commit (previous commit).

4. It updates the HEAD pointer to this new commit.

Hash Codes (SHA-1)

You must have seen those long strings like a1b2c3d4…… next to your commits.

These are SHA-1 Hashes. Git takes the content of an Object (Blob, Tree or Commit) and genereates a unique 40-character ID.

Integrity: Even if you change a single comma in file, Hashes changes completely.

This means no one can ulter the code history without breaking the chain. This makes git incredibly secure and reliable.

Conclusion

Git isn’t a tool for saving work, It is a beatiful system of pointers and snapshots.

• The .git folder is the database.

• Blobs holds data, Tree holds structure and Commits hold history.

• Everything is secured by Hashes.

Imagine Playing a video game without “Save Points”. One wrong move, and you lose hours of progress. Frustrating, right?

That used to be the reality of software development. Before the era of Version Control Systems (VCSs), we lived in the age of “The Pendrive Problem” - manual backups, overwritten files, and zero collaboration safety.

Today, we take git push for granted, but do you know the nightmare that existed before it?

The Problem: Why "The Pendrive Method" Fails 📉

To understand why we need Git, let's look at a real-world scenario. Let's imagine a team of developers trying to build a project using just a pendrive or email.

Scenario 1: The "Overwrite" Disaster (2 Developers)

Imagine Dev A and Dev B are working together.

1. Dev A writes the code for the Login Page and gives the file to Dev B via a pendrive.

2. Dev B starts working on the file to add a Signup Page.

3. The Conflict: While Dev B is working, Dev A doesn't stop. He stays on his laptop and fixes a bug in the Login Page.

Now we have a problem:

• Dev A has the fixed bug (but no Signup Page).

• Dev B has the Signup Page (but the old, buggy Login Page).

When they try to combine their code, they hit a dead end. If Dev A copies Dev B's folder, Dev A's bug fix gets deleted (overwritten). There is no way to merge these "parallel universes" automatically.

Scenario 2: The "Chaos Multiplier" (3 Developers)

If you think 2 people are hard to manage, see what happens when Dev C joins.

Dev A is working on Login.

1. Dev B is working on Payment.

2. Dev C starts working on a Search Bar.

Since they are all working on separate laptops without a central server:

• Dev C asks for the code. Dev A gives him an outdated version that doesn't have Dev B's work.

• Now we have 3 separate projects running on 3 laptops.

• To fix this, someone has to manually copy-paste code from 3 different sources line-by-line.

The Result? It becomes a spider web of confusion. Adding more developers doesn't speed up the work—it stops the work entirely because you spend all your time fixing copy-paste errors.

The 3 Major Pain Points

As we saw in the scenarios above, manual collaboration leads to:

1. Tracking Issues: You cannot track who changed the code. Did Dev A break the button, or was it Dev C?

2. The "Undo" Problem: If you make a mistake and save the file, the previous working code is gone forever.

3. No Collaboration: After a few days, the files become so different that you can't work together anymore.

The Solution: Version Control Systems(VCSs)

So, how do we stop the madness of final_v2.zip? The answer is a Version Control System (VCS).

Think of VCS as a superpower for your code. It solves every single problem we faced in the "Pendrive Era" by introducing three major concepts:

1. The Time Machine (Solves "The Undo Problem")

In the old days, if you made a mistake and saved the file, the old code was gone forever.

• With VCS: It takes a snapshot (called a Commit) of your entire project every time you save.

• The Benefit: If the current code crashes, you can travel back in time to yesterday's version with one command.

2. Parallel Universes (Solves "The Overwriting Disaster")

Remember how Dev A deleted Dev B's code by accident? VCS solves this with Branches.

• How it works: Imagine creating a copy of the world. Dev A works in Universe A (Branch A) and Dev B works in Universe B (Branch B).

• The Benefit: Both can work on the same file at the same time without disturbing each other. When they are done, the VCS intelligently merges the universes together. No more accidental overwrites!

3. The Central Hub (Solves "The Pendrive Problem")

Instead of passing physical pendrives or emailing zips, everyone connects to a Central Server (like GitHub).

• How it works: Dev A pushes code to the Hub -> Dev B pulls it from the Hub.

• The Benefit: Everyone is always synced with the latest version. The "Central Hub" acts as the single source of truth.

Is Git the Only Option? (Examples of VCS)

While Git is the most popular tool (used by 90% of companies), "Version Control" is a concept, and there are other tools out there:

1. Git (The King ): The industry standard. It’s fast, free, and distributed (everyone has a full copy of the history).

2. SVN (Subversion): An older, centralized system. Used by some legacy enterprise companies.

3. Perforce (Helix Core): Popular in the Gaming Industry (e.g., Ubisoft) because it handles huge art and audio files better than Git.

Conclusion: Ditch the Pendrive, embrace the Future

If you are still naming your folders project_final_final_v2.zip, it is time to stop.

The "Pendrive Era" was full of stress, overwritten code, and broken friendships. Today, we have tools like Git that handle the chaos for us. It might feel intimidating to type commands into a black terminal screen at first, but trust me—it is a superpower every developer needs.

The takeaway is simple:

• Manual Backups = Risk of losing everything.

• Version Control = Peace of mind and easy collaboration.

So, throw away that pendrive, install Git, and type your first command: git init. Your future self (and your teammates) will thank you.

Happy Coding! 💻