Blog
3 min read

"fatal: not a git repository": What It Means and How to Fix It

Git can't find a .git folder in the current directory or any parent. The usual causes — wrong folder, never ran git init, a deleted or broken .git, Docker builds and CI without Git history, safe.directory ownership checks — and the fix for each.

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

Git commands only work inside a repository — a folder that contains a hidden .git directory holding the project's history. This error means Git looked in your current folder, then each parent folder up to the root, and found no .git anywhere.

Cause 1: you're in the wrong folder (most common)

Check where you are:

pwd          # macOS / Linux / Git Bash
cd           # Windows Command Prompt

Then move into the project:

cd ~/projects/my-app
git status

A classic version: you cloned a repo, which created a new folder, but you're still in the folder above it. After git clone, always cd into the new folder. (git clone explained, The terminal for beginners)

Cause 2: the project was never a Git repository

If you downloaded a ZIP, copied files, or an AI tool created a project without Git, there's no .git folder. Create one:

git init
git add .
git commit -m "First commit"

Then connect it to GitHub if you like. (git remote add origin)

Cause 3: the .git folder was deleted or damaged

Check it's there (it's hidden):

ls -a          # macOS / Linux
dir /a         # Windows

If you deleted it, the local history is gone. If the project is on GitHub, the simplest recovery is to clone it fresh and copy over any uncommitted files.

Cause 4: Git refuses because of folder ownership

On shared machines, WSL, Docker volumes and CI, you might instead see:

fatal: detected dubious ownership in repository at '/workspace/app'

Git refuses to work in a repository owned by a different user, as a security measure. If you trust the folder:

git config --global --add safe.directory /workspace/app

Better still, fix the ownership so your user owns the files. (Linux file permissions)

Cause 5: inside Docker or CI

Build steps that call Git (to get the commit hash, for example) fail when:

  • .git is in .dockerignore — so it's not copied into the image. That's usually correct; pass the commit hash in as a build argument instead:

    docker build --build-arg COMMIT_SHA=$(git rev-parse HEAD) .
    
  • The CI checkout is shallow or missing. Make sure the workflow checks out the repo first (actions/checkout), and use fetch-depth: 0 if a step needs full history. (GitHub Actions CI basics)

Cause 6: a tool runs in a different directory

Editors, scripts and package scripts sometimes run Git from a folder you didn't expect. In a script, cd to the project first, or use git -C /path/to/repo status.

Quick checks

pwd                         # where am I?
ls -a                       # is there a .git here?
git rev-parse --show-toplevel   # where's the repo root (if any)?

EasySpawn sets your project up on a server as a proper Git repository from the start, so every change Claude Code makes is tracked and reversible. See how it works or join the waitlist.

Related: Git and GitHub for Beginners · git remote add origin · The Terminal for Complete Beginners · File Paths Explained

Keep reading