What are the main entries inside a Git repository's .git directory, and what does each hold?

## Why this gets asked It separates people who have opened `.git` from people who have only run commands against it. Everything Git does is reading and writing these files, so being able to name them means the mental model is concrete rather than magical. ## The top-level files **`HEAD`** — a single line. Normally `ref: refs/heads/main`, meaning "the current branch is main". In a detached checkout it contains a raw commit ID instead. Almost every command starts by reading this file. **`config`** — the repository-local configuration in INI format: remote URLs and fetch refspecs, per-branch upstream settings, and any local overrides of user or system settings. This file is per-clone and never committed. **`index`** — a binary file, the staging area. It lists every tracked path with its blob ID, file mode and stat data. It is what `git add` writes and what `git commit` turns into a tree; it is also why `git status` is fast, because cached stat data lets Git skip unchanged files. **`packed-refs`** — refs that have been packed into one file rather than kept as individual loose files, for repositories with many branches and tags. **`description`** — a legacy one-liner used by the `gitweb` viewer; it plays no part in ordinary use. Transient markers appear as needed: `COMMIT_EDITMSG` holds the message you last edited, `ORIG_HEAD` records where HEAD was before a potentially disruptive operation such as a merge or reset, `MERGE_HEAD` exists while a merge is in progress, and `FETCH_HEAD` records what the last fetch retrieved. ## The directories **`objects/`** — the database. Loose objects are stored one file per object under a two-character prefix directory taken from the object's hash; packfiles and their indexes live in `objects/pack/`. This is the only place your content actually exists. **`refs/`** — names pointing at object IDs. `refs/heads/` holds local branches, `refs/tags/` holds tags, `refs/remotes/` holds remote-tracking refs. Each loose ref is a file containing an object ID. **`logs/`** — reflogs. `logs/HEAD` records every movement of HEAD, and `logs/refs/heads/<branch>` records movements of each branch. These are local, are not fetched or pushed, and are what makes recovering an overwritten branch tip possible. **`hooks/`** — executable scripts Git runs at defined points. A fresh repository contains only disabled `.sample` files; a hook becomes active when a correctly named executable file exists here. Note that `.git/hooks` is not committed, which is why teams reach for shared hook directories or a hook manager instead. **`info/`** — repository-local metadata that is not committed, most importantly `info/exclude`, which holds ignore patterns that apply to this clone only and never appear in a commit. ## Reading it safely Inspecting these files is harmless: `cat .git/HEAD`, `cat .git/refs/heads/main`, `ls .git/objects` all just read. Writing them by hand is not — object files are compressed, `index` is a binary format, and refs have update semantics involving the reflog. The supported way to write is through commands such as `git update-ref` and `git symbolic-ref`. One more useful fact: the location of this directory is not fixed. `git rev-parse --git-dir` prints where Git decided it is, `--show-toplevel` prints the working tree root, and `--is-bare-repository` tells you whether there is a working tree at all. ## The frequent mistakes Saying that `.git` contains "the previous versions of the files as files" — it contains objects addressed by hash, not a per-version folder tree. Saying that hooks are shared with clones — they are not, because `.git` is not part of any commit. And confusing `.git/info/exclude` with a committed ignore file: both express ignore patterns, but only one of them travels to other clones.