Remove Git tracking from a directory initialized with git init

Remove a standalone repository’s .git directory while keeping its files, check local-only work first, and distinguish linked worktrees, submodules, and remote deletion.

Best practices
Illustration of Git branches and version history

For a normal standalone repository created by git init, deleting its .git directory removes the local Git metadata while leaving the project files in place. That also removes local branches, stashes, repository configuration, and history stored only there.

Confirm the repository layout first

git rev-parse --show-toplevel
git rev-parse --git-dir
git status --short
git stash list
git remote -v

Check that the reported root is the project you intend to detach. An ordinary repository has a .git directory at that root. A linked worktree or submodule can instead have a .git file pointing to metadata elsewhere; deleting that file is not equivalent to removing a standalone repository. Use the appropriate worktree or submodule workflow for those layouts.

To inspect local commits not reachable from your currently fetched remote-tracking refs:

git log --oneline --branches --not --remotes

This is a useful local comparison, not proof that the server has or lacks a commit: remote-tracking refs may be stale, and local tags or other refs need separate consideration. Back up any history or stashes you need before deleting metadata.

Keep files and remove the standalone metadata

After confirming the path and backing up what matters:

cd /path/to/project
rm -rf -- .git

On Windows, show hidden items in File Explorer and delete the confirmed .git directory. The remaining files become an ordinary folder unless an enclosing parent repository also tracks them. .gitignore and similar files remain as ordinary files.

To delete the whole project instead, remove its directory only after confirming both its path and contents. For a standalone project on a Unix-like system:

rm -rf -- /path/to/project

Remote repositories are separate

Deleting local metadata does not delete a GitHub or GitLab project. Their settings provide separate repository or project deletion actions, subject to permissions, confirmation, and retention rules. Do that only when you intend to remove the remote project as well.

FAQ

Can I get the old history back?

Clone a surviving remote or restore a backup. A remote normally does not contain your local-only branches, edits, or stashes. Once the only copy of the metadata is gone, Git itself has nothing from which to recover it.

How do I start fresh while keeping the files?

After removing the old standalone metadata, run git init, review what should be ignored, then stage and commit the files you want. This creates unrelated history. Prefer a new remote destination; replacing an existing shared history requires a separate coordinated rewrite, not an automatic force push.

Why does a nested directory have its own .git?

It may be an independent repository, a deliberately configured submodule, or an accidental nested clone. A nested repository is not automatically a correctly configured submodule. Inspect .gitmodules, the index, and the metadata path before removing anything inside it.

See git-init, git-worktree, GitHub repository deletion, and GitLab project management.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting