Fix 'Not a git repository' Error in 3 Steps

Why You're Seeing This

This error is Git's way of saying "I looked in this folder and the parent folders, but I can't find a .git directory." That directory is the heart of your repo — it holds all your commits, branches, and config. Without it, Git has no idea what you're talking about.

I've seen this trip up developers for years, and it's almost always one of three things: you're in the wrong directory, the .git folder got deleted, or you're working inside a submodule. The fix is usually simple, but let's walk through it from quickest to most involved.

Quick Fix (30 seconds): Check Your Location

First, confirm you're actually inside a Git repository. Run:

pwd

On Windows, that's cd with no arguments — it prints the current directory. Then check for a .git folder:

ls -a

If you see .git in the list, you're in a repo. So why the error? Try running git status again. If it still fails, your shell might be pointing to a different drive or location than you think. For example, on Windows, if you opened PowerShell in one location and then used cd to jump to a mapped drive, Git might be looking at the wrong path.

If you don't see .git, you're not in a repo. Maybe you cloned the project into a subfolder, or you're one level up from the actual repo root. Navigate around:

cd ..

Repeat the ls -a until you find the .git folder. That's your repo root. This sounds basic, but I can't count how many times a developer swore they were in the right folder when they were actually one directory too deep.

If you're in the right place and there's no .git, the repo might be corrupted or missing. Move to the next fix.

Moderate Fix (5 minutes): Re-initialize or Re-clone

If the .git folder is missing, you have two options. The quick one is to re-initialize the repo:

git init

This creates a fresh .git folder. But here's the catch — it doesn't restore your commit history. If you deleted the folder by accident, all your commits are gone. If you have a remote, you can pull the history back:

git remote add origin <your-remote-url>
git fetch origin
git reset --hard origin/main

Replace main with your actual branch name. This wipes any local changes, so only do it if you're sure you don't need them. If you don't have a remote, that history is gone. Sorry, no magic trick there.

If this is a project you cloned from GitHub or GitLab and you don't have local changes, the fastest fix is to re-clone:

cd ..
rm -rf broken-repo
git clone https://github.com/user/broken-repo.git
cd broken-repo

This gives you a clean copy with the full history. It's my go-to when the .git folder is mangled.

One more scenario: you're in a subfolder of a repo, and Git still says not a repository. That shouldn't happen — Git searches parent directories automatically. Unless the parent folder is named differently or the .git file is missing. Speaking of which, there's a special case with submodules. If you're inside a submodule that's not initialized, Git will throw this error. Run:

git submodule update --init

That pulls in the submodule's files, including its .git pointer. This only applies if you're in a project that uses submodules, but it's a common gotcha.

Advanced Fix (15+ minutes): Dig into the .git File and Permissions

If none of the above worked, something deeper is going on. Let's rule out a few things.

1. The .git is a File, Not a Directory

In submodules and some worktrees, .git is a regular file that points to the real location. Check what it is:

cat .git

If it's a file, it'll contain something like gitdir: /path/to/real/git. If that path is wrong or the folder doesn't exist, Git can't find the repo. Fix the path or recreate the file. For a normal repo, .git should be a directory. If it's a file and you didn't mean to have a submodule, delete it and re-init.

2. Permissions or Ownership Issues

On Linux or macOS, Git might not have permission to read the .git folder. Check with:

ls -la .git

If you see permission denied or odd ownership, fix it:

sudo chown -R $(whoami) .git

Or on Windows, right-click the folder, go to Properties > Security, and make sure your user has full control. This is rare, but I've seen it after copying a repo from an external drive or an old machine.

3. Environment Variables or Aliases

Sometimes Git is aliased to a different command, or your GIT_DIR environment variable is set to a non-existent path. Check:

echo $GIT_DIR

If it's set, unset it:

unset GIT_DIR

And verify your git alias isn't overriding things:

alias git

If it's aliased to something weird like git='git --git-dir=/wrong/path', that's your culprit. Remove the alias.

4. Corrupted Index or Config

If the .git folder exists but Git still complains, the index or config files might be corrupted. Back up and delete the index:

mv .git/index .git/index.bak
git reset

This rebuilds the index from the current HEAD. If that doesn't work, check .git/config for weird entries. If all else fails, you can clone the remote into a fresh folder and manually copy over any uncommitted changes.

When to Give Up and Start Fresh

If you've tried all this and Git still won't cooperate, it's not worth more time. Back up your working files, clone the repo again, and reapply any changes. It's painful but faster than fighting a corrupted .git folder for hours. Trust me — I've been there.

Tip: To avoid this in the future, don't delete the .git folder when cleaning up. And if you're moving a repo, zip the whole thing. I've seen too many people lose history by copying only the visible files.

Remember: Git's error messages are blunt, but they're usually accurate. If it says "not a repository," it genuinely can't find the folder. Fix the location, and you're back in business.