How Git Works and What the .git Folder Does

We've all been there. You type git add ., then git commit, and then git push. But have you ever thought about where the code really goes?
The code does not immediately disappear into the cloud. It goes into a folder on your computer that you can't see.
For most developers, Git is like a "black box" that we don't want to touch. We memorize the commands, cross our fingers, and hope we don't mess anything up. But today, we're going to break that box open.
At the end of this article, you won't just know what to type; you'll be able to picture what happens inside the machine when you hit Enter.

1. What is Git, really?

For a moment, forget about the technical terms.
Git is basically a Content-Addressable Filesystem.
That sounds scary, but it just means that Git is a more basic version of a database. It's a store of keys and values.
The Key: A hash, which is a unique ID.
The Value: The things in your file.
Git doesn't keep "changes" or "differences" like the "Pendrive Method" did when we saved project_final_v2. It keeps pictures. When you commit, Git takes a picture of your whole filesystem at that exact moment. To save space, it just links back to the last picture if the file hasn't changed.

2. The .git Folder: The Brain of the Operation

When you run git init in a project, Git makes a secret folder called .git.
This folder is more than just a config file. Your project is this. You can get back your working files (the code you can see) by using the .git folder if you delete them. But if you delete the .git folder, all of your project's history, branches, and versions are gone for good.
Let's take a look inside. When you open it, you'll see something like this:
There are a lot of files, but three are very important:

• HEAD: A text file that tells you where you are. It lets Git know what branch you are on right now.

• refs/: This folder has your bookmarks in it. It has links to your branches (like main) and tags.

• objects/: This is where the database is. This is where all your files, commits, and folder structures are kept, in a compressed and encrypted form.

3. Git Objects: The Parts That Make Up Git

You need to know the three "nouns" of the Git language in order to understand how Git keeps track of your code.
You can think of Git as a photo album.

• The Blob (Binary Large Object)
  The Picture as an Analogy. Git doesn't care about the filename when you give it a file; it only cares about the content. It puts the data into a "Blob" and compresses it.

  Fact: Git only saves one Blob if two files in different folders have the same text. It works very well.

• The Tree
  The Page in the Album is an example. A Blob has something in it, but it doesn't have a name. That's where the Tree comes in. A Tree object is similar to a list of files. It connects names to Blobs.

  For example, "The file login.js is at Blob ID a1b2c3...".

• The Commit
  This is like the album cover. This is the thing you know the most about. A commit ties everything together. It has:
  The Tree: A picture of the project at that time.
  Author, Date, and Message are all examples of metadata.
  The Parent: A link to the commit that came before it.

4. How do git adds and git commits operate in the background?

We know the players (Blob, Tree, and Commit), so let's watch them play the game.

Step 1: git add .
You aren't just "preparing" files when you run this command. You are adding to the database right now.
Git reads the contents of the file.
For each file, it makes a Blob object and puts it in .git/objects.
It tells the "Index" (Staging Area) to use this new Blob for the next snapshot.
Even before you commit, your code is safely stored in the .git folder as a Blob!

Step 2: Type "git commit -m "Save work"
This is where the snapshot stays forever.
Git makes a Tree object that shows how the Staging Area's folders are set up right now.
Git makes a commit object that links to that Tree.
Git changes the main branch pointer to point to this new commit.

5. Is it possible for Git to make mistakes? (The Check for Integrity)

You might be wondering, "What happens if a hard drive error messes up a file?" Will Git find out?

Yes. This is why Git uses those strange strings of 40 characters, like e4d909...
A SHA-1 Hash is what this is. Git makes this ID based on what is in the file. It is a fingerprint in math.
The file gets a new Hash ID if you change even one semicolon in your code.
If a file on your disk gets corrupted, the content won't match the ID anymore, and Git will let you know right away.
This makes Git unchangeable. You can't change history without anyone knowing because the IDs would break. This capability is why we trust Git with our most important medical and financial software.

Last Thoughts

When you realize that Git is just a graph of blobs (files), trees (folders), and commits (snapshots), the fear goes away.

When you execute commands, you are not wielding magical powers. All you're doing is making new snapshots and moving pointers around. The .git folder isn't a mystery; it's just a well-organized filing cabinet.

So, the next time you type "git commit," imagine that the new Commit object is connecting back to its parent. This will make a perfect, unbreakable chain of history.