How to fix fatal: this operation must be run in a work tree in Git

The most common cause is accidentally navigating into the .git folder. Check your current location:

pwd

If the path ends in .git, move back up to the repository root:

cd ..
git status

Git commands should now work normally.

Ask Git directly whether it considers the current repository bare:

git rev-parse --is-bare-repository

If this returns true, you are in a bare repository. You can also inspect the directory:

ls -la

A bare repository contains entries like objects/, refs/, HEAD, and config directly in the current directory, with no .git subdirectory and no source files.

If you need a working copy of a bare repository, clone it. This is the simplest and safest way to get a normal repository with a working tree:

# If the bare repo is local
git clone /path/to/bare-repo.git my-working-copy
cd my-working-copy

# If it's a remote bare repo
git clone git@server:/path/to/repo.git my-working-copy
cd my-working-copy

The clone leaves the original bare repository untouched and gives you a normal checkout where all Git commands work.

If a repository that *does* contain source files suddenly shows this error, check whether core.bare was incorrectly set to true:

git config --get core.bare

If it returns true but this is supposed to be a normal working repository, reset it:

git config core.bare false

You can also open .git/config and change the bare = true line under [core] to bare = false. Run git status afterward to confirm the working tree is recognized again.

To run a single command against a bare repository while pointing at an external working tree, use the --work-tree option (place global options before the subcommand):

# Run status using a separate work tree
git --work-tree=/path/to/files status

# Checkout files into a specific directory
git --work-tree=/var/www/html checkout <branch>

The equivalent environment-variable form for a single command:

GIT_WORK_TREE=/path/to/files git status

For a server that should always associate a work tree with a repository, you can set core.worktree. Note that core.worktree is ignored while core.bare is true, so for a true push-to-deploy setup it is cleaner to keep the repo bare and pass GIT_WORK_TREE from a hook rather than mixing settings.

The standard push-to-deploy pattern uses a bare repository plus a post-receive hook:

#!/bin/bash
# .git/hooks/post-receive in the bare repo
git --work-tree=/var/www/mysite --git-dir=. checkout -f

Here checkout -f overwrites the deploy directory with the pushed commit, which is the intended behavior for an automated deploy target that no one edits by hand. Do not point such a hook at a directory containing manual edits, since they would be discarded.

GIT_DIR and GIT_WORK_TREE override Git's automatic repository detection and can trigger this error if left set from a previous command or script. Check them:

echo "$GIT_DIR"
echo "$GIT_WORK_TREE"

If they are set and shouldn't be, unset them:

unset GIT_DIR
unset GIT_WORK_TREE

Or clear them for just one command:

env -u GIT_DIR -u GIT_WORK_TREE git status

If you genuinely need a working copy from a bare repository, clone it (as in step 3) rather than restructuring the original directory. Cloning is safe, preserves the original bare repo as a backup, and checks out the correct default branch automatically:

git clone /path/to/bare-repo.git /path/to/working-repo
cd /path/to/working-repo

Only if you must convert a bare repo *in place* (for example, it is the single source of truth and disk space is tight) should you flip its configuration. Do this on a copy you can afford to lose, and detect the branch name dynamically instead of assuming master:

# Work on a COPY of the bare repo, not your only copy
cd /path/to/bare-repo.git

# Turn off bare mode and point the work tree at the current directory
git config core.bare false
git config core.worktree .

# Check out the actual default branch (do not hardcode master/main)
default_branch=$(git symbolic-ref --short HEAD)
git checkout "$default_branch"

This leaves the Git internals in the current directory rather than in a .git subfolder, which is unusual but valid. Because this in-place conversion is easy to get into a half-broken state, the clone approach above is strongly recommended unless you have a specific reason not to use it.