Inside Git: How It Works and the Role of the .git Folder
Aspiring Full-Stack Developer
The .git folder is where Git stores everything about your project’s history. Every commit you’ve ever made, every file version, every branch pointer » all of it lives here.
If you’re curious, you can explore it yourself. The .git folder is hidden by default, but once you list hidden files, you can open it and see what’s inside. At first, it looks confusing, but each part has a clear purpose.
The HEAD File
One of the first things you’ll notice is a file called HEAD . This file is extremely important.
HEAD is basically a pointer. It tells Git where you are right now in your project’s history. Most of the time, it points to the latest commit of the current branch.
If you switch branches or move to an older commit, Git doesn’t copy files around randomly. It simply moves the HEAD pointer to a different place in the history. That’s why switching branches feels instant
Git is just changing references, not rewriting everything.
Config » Repository Settings
Inside the .git folder, you’ll also find a config file. This stores configuration related to the repository, such as:
Your username and email
Remote repository URLs
Project-level Git settings
This config applies only to that specific repository. Git doesn’t touch other folders or projects on your system. Every project has its own .git folder and stays completely isolated.
Logs » History Record
There’s also a logs folder. This is where Git keeps metadata about commits as they happen. When you run git log, Git reads from here to show you your commit history.
Think of logs as a readable timeline of what happened, who did it, and when. It’s not the actual file data just the history information.
Objects » The main asset of Git
The most important part of the .git folder is the objects directory. This is where Git stores all versions of all files, compressed and organized for fast access.
Whenever you run git commit, Git does a few things:
It takes your current files.
Compresses them using the zlib library.
Generates a unique SHA-1 hash for each piece of data.
Stores everything inside the
objectsfolder.
Git creates three types of objects:
Blob objects »store the actual content of files
Tree objects »represent folder structures
Commit objects » store commit metadata like author, message, parent commit, and the tree reference
This is why Git is so fast and reliable. Instead of saving full copies again and again, it stores content efficiently and reuses objects when possible.
Exploring Objects with git cat-file
If you really want to see what’s happening internally, Git gives you a command called git cat-file.
You can start by running git log to get a commit hash. That long hash uniquely identifies a commit. Once you have it, you can do:
git cat-file -t <hash>to see what type of object it isgit cat-file -p <hash>to print its contents
For a commit object, you’ll see things like:
Author
Commit message
Parent commit hash
Tree hash
If you take the tree hash and inspect it, Git will tell you it’s a tree object. Printing it shows the files and folders in that commit. Each file points to a blob hash, and inspecting that blob shows the actual file content.
Once you do this a few times, Git’s internal model becomes very clear.
Why Objects Are Stored in Subfolders ??
Inside the objects folder, you’ll notice many subfolders with short names like c8, 12, etc. These are based on the first two characters of the object’s hash.
This isn’t random. It’s an optimization. Instead of putting thousands of files in one folder, Git spreads them out so objects can be found faster.
Git’s Scope and Security
Git only operates inside the folder where the .git directory exists. It doesn’t access parent folders or other projects. You can have hundreds of Git repositories on your computer, and each one is fully independent.
That’s why cloning a repo into a new location works so well. Each clone has its own .git folder managing its own history.
Working with Multiple Copies and Conflicts
A common way to understand Git better is to clone the same repository into two different folders. Make changes in one, commit and push them, then pull those changes into the other. You’ll see Git syncing history cleanly.
If two people change different files, Git merges them automatically. Even if they change different parts of the same file, Git often handles it.
But if both people edit the same lines, Git stops and asks for help. It shows both versions side by side and lets a human decide what should stay. Once resolved, Git creates a new commit and moves forward.
The Index (Staging Area)
One last important piece is the index, also known as the staging area. This is where Git stores information about what will go into the next commit.
When you run git add, Git records those changes in the index. When you run git commit, Git uses the index as the source of truth for what should be committed.
This gives you fine control over commits, especially in large projects.