Git “index.lock File Exists”: How to Fix It

The Git error .git/index.lock: File exists means Git cannot acquire the lock it uses while updating the repository index. Another Git command may still be running, or a previous command may have stopped and left a stale lock behind. Do not delete the lock until you have confirmed no Git operation is active.

Why does Git create index.lock?

Git creates index.lock while it writes an updated staging index, then renames that temporary file into place when the update succeeds. If another Git process is already doing this, a second process waits or reports that the lock exists. A crash, interrupted command, or forced shutdown can also leave the lock behind.

The lock protects repository data from simultaneous writes. Removing it while Git is using it can interfere with an operation, so first check whether your terminal, editor, Git client, or background task is still running Git.

Step 1: Wait for or stop the active Git operation

• Check other terminal tabs for a running commit, checkout, merge, reset, or other Git command.
• Check your editor’s source control view and any Git GUI or background tool that may be updating this repository.
• Let the operation finish if it is making progress. If it is stuck, close or stop it using the tool that started it, then wait for it to exit.

Do not start another index-changing command or delete the lock while an operation is still running. Once it finishes, retry the original command.

Step 2: Locate the repository’s index lock

If no Git operation is running, ask Git for the lock’s actual path and inspect it:

git rev-parse --git-path index.lock
ls -l "$(git rev-parse --git-path index.lock)"

Using git rev-parse is more reliable than assuming .git is a directory: worktrees and some submodule setups keep Git metadata elsewhere. If the lock has already disappeared, retry the original operation instead of removing anything.

Step 3: Remove a stale lock and retry

Only if you have confirmed that no Git process is operating on this repository and the lock still exists, remove that exact file:

rm "$(git rev-parse --git-path index.lock)"

This command targets the repository’s index.lock only. Do not delete .git/index, remove the whole .git directory, or use a wildcard to clear lock files; those actions can damage repository state.

Retry the Git command that failed. If it succeeds, inspect the working tree and staged changes with git status and git diff --staged before continuing.

If the error keeps coming back

• Confirm that an editor, Git GUI, file watcher, or script is not repeatedly starting overlapping Git operations.
• Check that the repository is on a writable local filesystem and that your account has permission to update its Git metadata.
• If a Git operation was interrupted, inspect git status after the stale lock is cleared. Complete or abort an in-progress merge or rebase with the appropriate Git command rather than deleting its state files.

If the repository reports broader corruption or repeated write failures, preserve a copy of the project and investigate the filesystem or storage before running repair commands.

Common questions

Is it safe to delete index.lock?

Only when you have confirmed no Git process is currently using the repository and the lock is left over from an interrupted operation. Removing a live lock can disrupt a write.

Should I delete .git/index instead?

No. index is Git’s staging index; index.lock is the temporary lock file involved in this error. Delete neither casually, and never substitute the index path for the lock path.