skip to content

What happens to your project if you delete the .git directory in a Git repository?

level: juniorimportance: should knowfreq 42%

answer

  1. Ask what actually lives in that folder
  2. Working-tree files are a checkout, not the source of truth
  3. Think about branches, tags and reflog
  4. Consider what a fresh clone would restore
  5. Unpushed work has no other copy

basics

~20 s

Your files stay exactly as they are on disk, but the folder stops being a Git repository: all history, branches, tags, stashes and configured remotes are gone, because .git is the entire repository and the working tree is only a checkout of it.

solid answer

~40 s

Everything Git knows lives inside `.git` — the object database, the refs, `HEAD`, the index, the reflogs and the repository config. Delete it and the surrounding directory becomes an ordinary folder of files; nothing in the working tree changes, but `git status` now reports that this is not a Git repository. Every commit, branch, tag, stash entry and remote URL disappears with it, and the reflog goes too, so the usual local recovery routes are unavailable. If the work was pushed, you can re-clone and copy your files back in; if it was never pushed, only a filesystem backup will save it. The inverse is also worth knowing: copying the `.git` directory alone to another machine gives you the complete history there, and a checkout can be recreated from it.

code

console · 5 lines
console
$ rm -rf .git
$ git status
fatal: not a git repository (or any of the parent directories): .git
$ ls
README.md  src/  package.json

go deeper

for a junior

Be able to say the files stay and the history goes, and that .git is the repository itself rather than a settings folder.

for a middle

Enumerate what is lost — objects, refs, index, reflog, stashes, remotes, local config — and explain that the working tree is just a checkout of one commit.

for a senior

Treat it as a data-loss scenario: know what is recoverable from a remote, what is not, and why .git must be excluded from deployment archives that leave your control.

for a principal

Own the policy side — backup expectations for developer machines, how much unpushed work the organisation tolerates, and where repository copies are allowed to travel.

## The repository is the .git directory In Git, the repository and the working tree are two different things that happen to sit next to each other. The **repository** is `.git`: the object database (`objects/`), the refs (`refs/`, `packed-refs`), the symbolic ref `HEAD`, the staging area (`index`), the reflogs (`logs/`) and the repository-local config (`config`). The **working tree** is the ordinary files around it — a materialised copy of one commit plus whatever you have edited since. Deleting `.git` therefore does not delete any of your source files. It deletes the version-control system's entire state. ## What exactly is lost - **All history.** Every commit object, tree and blob lived in `.git/objects`. - **All refs.** Branches, tags and remote-tracking refs are files under `.git/refs` (or lines in `.git/packed-refs`). - **The staging area.** `.git/index` recorded what was staged; that is gone, though the file contents in the working tree are untouched. - **The reflogs.** `.git/logs` is what makes "I reset too hard, get it back" possible. Without it the safety net is gone. - **Stashes.** A stash entry is a commit referenced by `refs/stash` and its reflog; both lived in `.git`. - **Local configuration.** Remote URLs, the upstream of each branch, hooks in `.git/hooks`, and local ignore patterns in `.git/info/exclude`. What survives: every tracked file's current content, every untracked file, and anything ignored — because none of those live in `.git`. ## Recovery If the history was pushed somewhere, recovery is straightforward: clone the repository again and copy your current files over the fresh checkout, then commit whatever differs. If it was never pushed and there is no backup or filesystem snapshot, the history is unrecoverable — no amount of Git knowledge helps, because there is nothing left to read. A nuance worth stating: deleting `.git` is not the same as `git rm -r` or `git clean`. Those act on tracked or untracked files in the working tree and leave the repository intact. Deleting `.git` is the exact opposite — repository gone, files intact. ## The mirror image Because the repository is self-contained, the reverse operation works too. Copy just the `.git` directory somewhere else and you have the whole history; `git checkout` or `git reset --hard HEAD` will rebuild a working tree from it. That is also the intuition behind a **bare** repository: the same contents with no working tree wrapped around them, which is what a server hosts. It is also why `.git` should be excluded when you archive or deploy a project directory: shipping it hands over the entire history, including anything ever committed and later removed. ## Why an interviewer asks The question checks whether you understand that Git is not a service your files talk to, but a database sitting in a folder. Candidates who think history is stored "in the files" or "on GitHub" give themselves away here. The strongest answers add the practical consequence: a repository is a directory you can copy, back up, and move, and a lost `.git` with unpushed work is a real data-loss incident.

  • If the work was pushed to a remote, how do you recover?
    Clone the repository again into a new directory, then copy your current working files over the fresh checkout and commit whatever differs. You get all pushed history back; anything committed locally but never pushed is still gone, since those objects only existed in the deleted `.git`.
  • How is deleting .git different from running git clean -fd?
    `git clean -fd` removes untracked files and directories from the working tree while leaving the repository intact. Deleting `.git` is the reverse: every file stays on disk and the entire history, refs and configuration are destroyed.
  • What does it mean that you can copy a .git directory to another machine?
    The repository is self-contained, so the copy carries all objects, refs and configuration. Running `git checkout` or `git reset --hard HEAD` against it materialises a working tree. A bare repository is essentially this: the same contents with no working tree attached.

The working tree is a printout on your desk; .git is the filing cabinet with every past version. Burning the cabinet leaves the printout but destroys the archive.

saying these in an interview costs you the question

  • Thinks the source files are stored inside .git and vanish
  • Assumes GitHub keeps a copy of unpushed commits
  • Confuses deleting .git with git clean or git rm
  • Believes git init afterwards restores history
  • Ships .git inside a deployment archive without noticing

context

resolving links…