Git "Unable to Create '.git/index.lock': File Exists" Error Fix

This error means Git found an existing index.lock file and refuses to proceed, since that lock file's presence normally indicates another Git operation is currently in progress — but it's very commonly a leftover from a previous operation that was interrupted (crashed, killed, or force-quit) without properly cleaning up after itself, rather than a genuinely concurrent operation.

The Problem

Running almost any Git command fails immediately:

fatal: Unable to create '/path/to/repo/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again.

Why It Happens

Git uses lock files as a safety mechanism to prevent multiple simultaneous operations from corrupting the repository by modifying the same underlying data structures at the same time. Under normal circumstances, this lock file is created at the start of an operation and automatically removed once it completes — the error appears when Git finds an existing lock file and, correctly following its own safety design, refuses to proceed rather than risk a conflict with whatever created that lock. Common reasons the lock file is left behind despite no operation actually still running:

• A previous Git command was interrupted — the terminal was closed, the process was killed, the computer lost power or crashed — before it could complete and clean up its own lock file
• A GUI Git client or IDE integration crashed or was force-quit while performing a Git operation, leaving its lock file behind
• A genuinely concurrent Git operation actually is running (a background process, a separate terminal, an IDE's own auto-commit or auto-fetch feature) — this is the one case where simply removing the lock file would be genuinely unsafe

The Fix

First, confirm no Git operation is actually still running before removing anything — check for any Git processes currently active:

ps aux | grep git

If this shows a genuinely running Git process still actively working (not just this check itself appearing in the list), let it finish rather than removing the lock file, since a lock file protecting an actually-in-progress operation exists for a good reason, and removing it while that operation is still running could corrupt your repository.

If no Git process is actually running, confirming the lock file is indeed a stale leftover, safely remove it:

rm -f .git/index.lock

After removing the stale lock file, retry your original Git command, which should now proceed normally without the false "another process is running" restriction.

If you're unsure whether a process might still be running, or the situation is genuinely ambiguous, wait a short period and check again before removing the lock — a legitimate, currently-running Git operation on a very large repository or an unusually slow network connection can occasionally take longer than expected, and giving it a bit more time before concluding the lock is stale is a reasonably safe, low-cost precaution.

If this happens repeatedly, particularly if you're using an IDE or GUI Git client alongside command-line Git on the same repository, investigate whether that specific tool is prone to crashing or being interrupted during Git operations — some IDE integrations have known issues with certain repository configurations or very large repositories that make this kind of interruption more likely, and addressing the root cause (updating the tool, adjusting its configuration, or avoiding a specific problematic feature) prevents the lock file issue from recurring as frequently.

Still Not Working?

If removing index.lock resolves the immediate error but your repository seems to be in an inconsistent state afterward (unexpected staged changes, a partially completed commit, or other unusual behavior), the interrupted operation may have left the repository's index in a genuinely incomplete state, not just the lock file itself stale. Running git status carefully to review exactly what state the repository is actually in, and if anything looks wrong, resetting the index to match the last known-good commit (being careful to preserve any working directory changes you still need) is a more thorough recovery step than simply removing the lock file alone:

git status
# review carefully before taking further action
git reset  # resets the index (staged changes) without touching your working directory files