# Fix "fatal: not a git repository" URL: https://www.devopsness.com/blog/fix-git-not-a-repository Author: Kiril Urbonas Published: 2026-07-11 Updated: 2026-10-12 Categories: DevOps Tags: Beginner, DevOps, Debugging, Git, Version Control Summary: Git says it can't find a repo where you're standing. Nine times out of ten it's the wrong directory, a missing .git, or an ownership check. --- # Fix "fatal: not a git repository" You run `git status`, expecting the usual list of changed files, and instead git slaps you with: ``` fatal: not a git repository (or any of the parent directories): .git ``` This one trips up beginners and senior engineers alike, usually because git is telling the literal truth and we don't believe it. Git walks up from your current directory looking for a `.git` folder. It checks where you are, then the parent, then the parent of that, all the way to the filesystem root. If it never finds one, you get this error. That's the whole mechanism. Every fix below is just a different reason git couldn't find that folder. Let me walk through the causes in the order I actually hit them, most common first. ## You're in the wrong directory This is the boring answer and it's right most of the time. You opened a new terminal, or a script `cd`'d somewhere, and now you're standing in a folder that has nothing to do with your repo. Check where you are: ```bash pwd # /Users/kiril/Downloads ls -la | grep git # (nothing) ``` No `.git` here. Go to where your repo actually lives: ```bash cd ~/projects/my-app git status # On branch main # nothing to commit, working tree clean ``` Fixed. Before you do anything clever, run `pwd` and `ls -la`. I have wasted real minutes debugging git only to realise I was one directory too high. ## The folder was never a repo Sometimes there's genuinely no repository because you never made one. You created a folder, dropped some files in, and started running git commands as if it were already tracked. ```bash ls -la # total 8 # drwxr-xr-x 4 kiril staff 128 Jul 11 09:14 . # drwxr-xr-x 20 kiril staff 640 Jul 11 09:10 .. # -rw-r--r-- 1 kiril staff 42 Jul 11 09:14 main.py ``` No `.git` directory in that listing. If this folder should be a repo, initialise it: ```bash git init # Initialized empty Git repository in /Users/kiril/projects/thing/.git/ git add . git commit -m "initial commit" ``` If it's supposed to be a clone of something remote, don't `git init` on top of it. Clone it fresh into a new folder instead. ## You cloned into the wrong place, or .git got deleted A close cousin. You cloned a repo, but the `.git` folder ended up somewhere you didn't expect, or someone (maybe a cleanup script, maybe you) deleted it. The tell is that all your files are present and correct, but git acts like it's never seen them. That's because the working files and the `.git` metadata are separate things. Delete `.git` and you've got a plain folder full of files with no history. ```bash ls -la # your files are all here... # but no .git directory ``` If you have a remote, the cleanest fix is to re-clone and copy your uncommitted work over: ```bash git clone git@github.com:you/my-app.git /tmp/my-app-fresh # then move any local-only changes into the fresh clone ``` Trying to resurrect a half-deleted `.git` is rarely worth it. Re-clone and move on. ## You're above the repo, not inside it Git only searches upward, never downward. If your repo is at `~/projects/my-app` and you're sitting in `~/projects`, git looks in `~/projects`, then `~`, then `/`, and finds nothing. It will never look *into* `my-app` for you. ```bash pwd # /Users/kiril/projects git log # fatal: not a git repository (or any of the parent directories): .git cd my-app git log # commit 4f1a9c2 (HEAD -> main) ... ``` One `cd` down and you're back in business. ## GIT_DIR is pointing somewhere wrong Less common, but nasty when it happens. Git respects the `GIT_DIR` environment variable. If some script or a stray line in your shell profile exported it to a path that doesn't exist, git will look there and only there, ignoring the `.git` under your feet. ```bash echo $GIT_DIR # /some/old/path/.git unset GIT_DIR git status # On branch main ``` If unsetting it fixes things, hunt down whatever set it. Check `~/.zshrc`, `~/.bashrc`, and any wrapper scripts you source. ## A submodule that was never initialised Clone a repo with submodules and the submodule folders show up empty. Step into one and run a git command, and you get the same error, because the submodule's `.git` link hasn't been populated yet. ```bash cd libs/shared git status # fatal: not a git repository ... cd ../.. git submodule update --init --recursive # Submodule path 'libs/shared': checked out 'a1b2c3d' ``` Now the submodule has its git data and behaves. ## "Detected dubious ownership" — the ownership variant This one wears a different mask. You'll see a message like: ``` fatal: detected dubious ownership in repository at '/repo' To add an exception for this directory, call: git config --global --add safe.directory /repo ``` The `.git` folder is right there, but git refuses to touch it because the directory is owned by a different user than the one running git. It's a security feature, added to stop a repo you don't own from executing config hooks as you. You hit it constantly in Docker containers, on mounted volumes, and after copying repos around with `sudo`. If you trust the repo, add the exception git already suggested: ```bash git config --global --add safe.directory /repo ``` Do not reach for `safe.directory *` to make it shut up everywhere. That switches off the protection wholesale. Add the specific paths you trust. In a container, fixing ownership at the source is cleaner: ```bash chown -R $(id -u):$(id -g) /repo ``` ## How to actually diagnose it Two commands settle almost every case. First, confirm whether a `.git` exists nearby: ```bash ls -la ``` Second, ask git where it thinks the repo root is: ```bash git rev-parse --show-toplevel # /Users/kiril/projects/my-app <- you're inside a repo # or: fatal: not a git repository <- you're not ``` If `--show-toplevel` prints a path, you're inside a repo and the error was likely a stale terminal or a `GIT_DIR` issue. If it errors, you're genuinely outside one, so it's a directory or an init problem. ## The call we'd make Run `pwd` and `ls -la` before you theorise. The overwhelming majority of these are you standing in the wrong folder, and you'll spot it in two seconds instead of two minutes. If the `.git` is present but git still balks, check for the dubious-ownership message and `GIT_DIR` before you assume anything is broken. Save the re-clone for when the `.git` is truly gone, and never blanket-whitelist `safe.directory *` just to silence a warning that exists to protect you. For the wider set of git failures, keep our [Git troubleshooting](/blog/git-error-troubleshooting-guide) guide within reach.