What I Was Trying to Do

I needed to make a small change to a tool a teammate had built and push it back up. I opened the repo on GitHub, clicked the “Code” button, chose “Download ZIP” instead of cloning, and unzipped it into my usual projects folder. As soon as I ran git status from inside it, Git refused to cooperate.

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

git add . and git log failed the same way. I was clearly standing inside what looked like the project, but Git wasn’t treating the directory as a repository at all.

Environment

  • OS: macOS Sonoma 14.5
  • Git: 2.45.1 (installed via Homebrew)
  • Terminal: iTerm2
  • How I got the code: GitHub’s “Download ZIP” button

What I Tried

My first guess was that something was wrong with Git itself, so I moved into a different project I already had cloned and ran git status there.

cd ~/projects/other-repo
git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

That worked fine, which ruled out Git being broken and pointed at the specific directory I’d just unzipped. So I looked inside it, including hidden files.

cd ~/Downloads/mytool-main
ls -la
total 32
drwxr-xr-x   8 acia  staff   256  7 23 10:12 .
drwx------@ 20 acia  staff   640  7 23 10:11 ..
-rw-r--r--   1 acia  staff  1071  7 23 10:12 README.md
-rw-r--r--   1 acia  staff   215  7 23 10:12 package.json
drwxr-xr-x   4 acia  staff   128  7 23 10:12 src

There was no .git directory anywhere in the listing. That’s when it clicked that downloading the ZIP was the actual cause.

Why This Happens

GitHub’s “Download ZIP” button packages up a snapshot of the files at that point in the branch’s history — nothing more. It doesn’t include the .git directory, which is where commit history, branches, and remote configuration actually live. git clone, by contrast, copies the entire .git metadata along with the files, which is what makes the result a real repository. A ZIP download only gives you “what the files currently look like,” so the extracted folder ends up being a plain directory that Git has no record of. git status walks up from the current directory looking for a .git folder, and when it can’t find one anywhere in the path, it reports this exact fatal error.

The same error also shows up in repositories that were properly cloned, if you accidentally cd out past the repository root into its parent directory, or if .git gets deleted somehow (for example by an overly broad rm -rf).

Solution

1. Confirm .git is actually missing

find ~/Downloads/mytool-main -maxdepth 1 -name ".git"
(no output — .git does not exist)

Once find comes back empty, it’s confirmed: this directory was never a Git repository to begin with.

2. Delete the ZIP copy and clone properly instead

rm -rf ~/Downloads/mytool-main
git clone git@github.com:example/mytool.git
cd mytool
Cloning into 'mytool'...
remote: Enumerating objects: 214, done.
remote: Counting objects: 100% (214/214), done.
remote: Compressing objects: 100% (150/150), done.
Receiving objects: 100% (214/214), 58.02 KiB | 2.90 MiB/s, done.
Resolving deltas: 100% (78/78), done.

git clone brings down the full .git directory along with the files — commit history, branches, and the origin remote all come with it.

3. Verify with git status again

git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

Since I was now standing inside a directory that actually contains .git, Git recognized it as a repository, and git add / git push worked normally from there.

4. If you just cd’d into the wrong place

Sometimes .git hasn’t been deleted at all — you’re simply one level too high or in the wrong folder. Check where you are and move into the actual repository root (the directory that contains .git).

pwd
cd mytool
git status

Gotchas

  • The unzipped folder was named mytool-main, with a -main suffix that made it look like a legitimate project directory at a glance, which delayed noticing that .git was missing.
  • Running git init makes the error go away, but it only creates a brand-new, empty repository local to that folder — it has no connection to the actual history on GitHub. The error disappearing doesn’t mean anything is fixed; git push afterward would try to push an unrelated history. Re-cloning is the correct fix, not git init.
  • I hit a similar-looking case once in a monorepo, where running commands from packages/foo triggered the same error. That wasn’t a missing .git — the repository root was simply a few directories higher up, and cd-ing back up to it resolved it immediately.

FAQ

Q: Won’t running git init just fix it? It makes the error disappear, but it creates a fresh, empty repository with no relationship to the project’s actual history on GitHub. If you want to continue working on the existing project, you need git clone, not git init.

Q: I got this error deep inside a monorepo subdirectory — is the subdirectory the problem? Usually not. A repository only has one .git, at its root, so a subdirectory by itself isn’t the cause. In most cases the terminal’s current directory has drifted outside the repository entirely. Run pwd to check where you are, then cd back into the directory that contains .git.

Q: I already made edits inside the ZIP folder — how do I keep them? Clone the repository fresh into a new folder, then copy just the files you changed over the top of the freshly cloned copy before committing. Going forward, cloning instead of downloading a ZIP avoids this problem entirely.