The .git folder is a hidden directory that Git automatically creates at the root of any project the moment you run git init, or that gets created for you automatically when you run git clone. It is, quite literally, the repository itself — every commit you’ve ever made, every branch you’ve ever created, every tag, every piece of configuration specific to that project, and the complete record of how all of it connects together, all stored as files and folders inside this one hidden directory.

Git needed somewhere to store an enormous amount of historical metadata — every past version of every file, who changed what and when, how branches relate to each other — without cluttering the actual project folder that you, your editor, and your build tools interact with daily. The solution was to keep the visible working files completely separate from the internal bookkeeping, tucking all of that bookkeeping into one hidden folder. This design keeps your project folder looking clean (just your actual code and files) while Git quietly maintains a complete, independent historical record right alongside it.

This separation is also precisely why Git can restore any past version of your project instantly: it never has to reach out anywhere else, because the entire history already lives locally, right next to the files it describes.

flowchart TD
    A[".git/ folder"] --> B["objects/
compressed history data"]
    A --> C["refs/
branch & tag pointers"]
    A --> D["HEAD
current checkout pointer"]
    A --> E["config
repo-specific settings"]
    A --> F["index
staging area state"]
    A --> G["logs/
reflog history"]
    

What an interviewer may ask: “Where does Git actually store your commit history?” Inside .git/objects, as compressed, hash-addressed objects — not as plain copies of your files sitting somewhere else on disk.

Every single Git command you run — git status, git commit, git log, git branch, git checkout — is really just Git reading from and writing to files inside .git. When you run git commit, Git takes what’s recorded in the index file, packages it into a new commit object, writes that object into objects/, and then updates the relevant file inside refs/ to point at the new commit. When you run git log, Git starts at HEAD, follows the chain of parent pointers stored inside each commit object, and prints the history it finds — no separate database, no external service, just files being read directly off your own disk.

Because the .git folder contains your project’s entire history — not just its current state — it can be a serious security risk if accidentally exposed. If a web server is misconfigured to serve a project’s root folder publicly, and the .git folder inside it isn’t blocked, an attacker can potentially reconstruct the full commit history, including old versions of files that were later “removed,” such as a config file that once contained a database password before being deleted in a later commit — deleting a file in a new commit does not erase it from earlier commits still sitting inside objects/.