Fix: fatal: not a git repository (or any of the parent directories): .git

The Error

You run any git command and get:

fatal: not a git repository (or any of the parent directories): .git

Why This Happens

Git stores all repository data in a hidden .git directory at the root of your project. Every time you run a git command, Git looks for this directory in the current folder, then in every parent folder above it. If it cannot find .git anywhere up the directory tree, it prints this error.

There are a few common reasons:

• You’re not inside a Git repository. You’re in a regular directory that was never initialized with git init or git clone.
• You’re in the wrong directory. Your repo exists, but your terminal is pointed somewhere else.
• The .git directory was deleted. Someone (or something) accidentally removed the .git folder. The project files are still there, but Git’s history and configuration are gone.
• Submodule or worktree misconfiguration. The .git reference file inside a submodule or worktree points to a location that no longer exists.

Fix 1: Initialize a New Repository

If you have a project folder that isn’t a Git repo yet, initialize one:

git init

This creates a .git directory in the current folder. You now have a working Git repository. Add your files and make your first commit:

git add .
git commit -m "Initial commit"

If you want to connect this repo to a remote (like GitHub):

git remote add origin https://github.com/your-user/your-repo.git
git push -u origin main

Note: If your default branch is master instead of main, use master in the push command. You can check with git branch. If the push is rejected, see Fix: git push rejected – non-fast-forward.

Fix 2: Navigate to the Correct Directory

The most common cause of this error is simply being in the wrong folder. Check where you are:

pwd

Then list the contents to see if a .git folder exists:

ls -la

If you don’t see .git, you’re probably one level above or below your actual repo. Navigate into it:

cd /path/to/your/project

A quick way to find your repo if you’re not sure where it is:

find ~ -name ".git" -type d 2>/dev/null

This searches your home directory for any .git directories. On large filesystems this can take a while, so you can narrow the search by replacing ~ with a more specific path.

Fix 3: Clone the Repository

If the repo exists on a remote like GitHub and you don’t have a local copy, clone it:

git clone https://github.com/your-user/your-repo.git
cd your-repo

A common mistake is running git pull or git status in an empty directory, expecting Git to somehow know which remote to use. Git doesn’t work that way. You must either git init or git clone first.

Fix 4: Reinitialize After an Accidentally Deleted .git Directory

If your project files are intact but the .git folder is gone, you’ve lost your local Git history. Here’s how to recover:

If the repo exists on a remote:

# Clone the repo into a temporary directory
git clone https://github.com/your-user/your-repo.git temp-repo

# Move the .git directory into your project
mv temp-repo/.git .

# Clean up
rm -rf temp-repo

# Check the state of your files against the last remote commit
git status

Your working files are still in place. git status will show any differences between your local files and the last commit on the remote. You can commit, discard, or selectively stage changes from here.

If no remote exists:

You cannot recover the Git history. But you can start fresh:

git init
git add .
git commit -m "Reinitialize repository"

Your commit history is gone, but your files are safe.

Fix 5: Submodule and Worktree Issues

Submodules

Inside a Git submodule, the .git entry is usually a file (not a directory) that points to the parent repository’s .git/modules/ folder:

gitdir: ../.git/modules/my-submodule

If the parent repo’s .git/modules/ folder was moved or deleted, the submodule’s .git reference becomes broken and you get the “not a git repository” error.

To fix this, re-initialize the submodules from the parent repository:

# Navigate to the parent repo root
cd /path/to/parent-repo

# Reinitialize submodules
git submodule deinit -f .
git submodule update --init --recursive

Worktrees

Git worktrees also use a .git file that points back to the main repository. If the main repo was moved or deleted, the worktree breaks.

Check the .git file in the worktree:

cat .git

It will contain something like:

gitdir: /original/path/to/repo/.git/worktrees/my-worktree

If that path no longer exists, you need to either move the main repository back or create a fresh worktree:

# From the main repo
git worktree remove my-worktree
git worktree add ../my-worktree branch-name

If the main repo’s worktree metadata is stale, prune it first:

git worktree prune

Still Not Working?

Git commands in scripts use the wrong working directory

If you’re running git commands inside a script (Bash, Python, Makefile, etc.), the working directory might not be what you expect. Always cd into the repo first or use the -C flag:

git -C /path/to/repo status

The -C flag tells Git to change to the specified directory before doing anything. This is more reliable than cd in scripts because it doesn’t affect the script’s working directory.

CI/CD environments

CI/CD runners (GitHub Actions, GitLab CI, Jenkins) check out code into a specific directory. If your pipeline steps change directories or run in a different working directory, Git won’t find the repo.

In GitHub Actions, the repo is checked out to $GITHUB_WORKSPACE. Make sure your commands run there:

- name: Run git command
  working-directory: ${{ github.workspace }}
  run: git status

In Jenkins, the repo is typically in $WORKSPACE. In GitLab CI, it’s in $CI_PROJECT_DIR.

If you’re using Docker containers inside CI, the repo might not be mounted into the container. Verify that the checkout directory is accessible. If Docker itself gives you permission errors, see Fix: Docker permission denied on the daemon socket.

Case-sensitive filesystems

On Linux, directory names are case-sensitive. If your path has a case mismatch (e.g., cd /home/user/MyProject when the actual directory is myproject), you’ll end up in a different directory or get an error. The .git directory name is always lowercase.

On macOS (which uses a case-insensitive filesystem by default), this is rarely a problem. On Windows, it depends on the filesystem configuration, but NTFS is case-insensitive by default.

Bare repositories

A bare repository (created with git clone --bare or git init --bare) has no working directory. The Git data lives directly in the folder instead of inside a .git subdirectory. Commands like git status won’t work at all (there’s no working tree). Commands like git log require you to specify the Git directory explicitly:

git --git-dir=/path/to/repo.git log

Bare repos are typically used as remotes (like on a server). You don’t normally work inside them. If you accidentally cloned with --bare, re-clone without it:

git clone https://github.com/your-user/your-repo.git

The GIT_DIR environment variable

If the GIT_DIR environment variable is set, Git uses that path instead of searching for .git in the directory tree. If it points to a nonexistent or incorrect path, every git command will fail.

Check if it’s set:

echo $GIT_DIR

If it returns a value and you didn’t set it intentionally, unset it:

unset GIT_DIR

To make this permanent, check your shell profile (~/.bashrc, ~/.zshrc, or ~/.bash_profile) for any lines that export GIT_DIR and remove them. For similar issues with environment variables not being set correctly, see Fix: environment variable is undefined.

Related: Fix: fatal: refusing to merge unrelated histories