How to Fix Git “Cannot Lock Ref” Errors

The Git error cannot lock ref means Git could not safely update a branch or tag reference. Another Git process may be using the repository, a previous operation may have left a stale lock, or two branch names may conflict on disk. Identify which case applies before deleting anything: the wrong cleanup can disrupt another Git operation or remove a branch you still need.

What “cannot lock ref” means

Git stores branch and tag pointers as refs. Before changing one, it creates a temporary lock so two operations do not update the same ref at once. The error often names the ref Git could not update, for example refs/remotes/origin/main. Read the complete message: text such as File exists, is at, or a path mentioning an existing file can point to different causes.

This is different from the Git index.lock error, which concerns the staging index. If the message specifically names .git/index.lock, follow the index.lock troubleshooting guide.

Step 1: Check for another Git operation

First, check other terminals, your editor, Git GUI, and background tasks for a running fetch, pull, checkout, commit, or branch update. Let it finish if it is progressing. Do not remove a lock while Git may still be using it.

If there is no active Git operation, check the exact ref and lock path mentioned in the error. Git can show where its metadata is stored, including in worktrees where .git is a file rather than a directory:

git rev-parse --git-dir
git status

Step 2: Resolve a stale lock file

A Git command that was interrupted can leave a ref-specific lock file behind, often ending in .lock. Only consider removing it after confirming that no Git process is operating on this repository. Use the full path shown in the error to inspect the lock, then remove that exact file if it is stale.

For example, if the error names .git/refs/remotes/origin/feature.lock, inspect that exact path and remove only that file after the checks above. Do not delete the named branch ref, the entire .git directory, or every file matching *.lock. If you are unsure which path is safe to remove, keep the repository unchanged and ask a maintainer for help.

Step 3: Check for conflicting branch names

If the error says a path exists as a file, but Git needs to create a directory beneath it, two ref names may conflict. For example, a local remote-tracking ref named refs/remotes/origin/release can conflict with a new remote branch named release/2026. Filesystems cannot represent both as a file and as a directory at the same path.

Inspect the remote and local branch names before changing refs:

git branch --all
git ls-remote --heads origin
git status

If the conflicting ref is an obsolete remote-tracking branch and the remote no longer has it, prune stale remote-tracking refs and fetch again:

git remote prune origin
git fetch origin

Pruning removes stale references only; it does not delete branches from the remote server. If pruning does not resolve the error, do not delete a local branch just because its name matches. Confirm which branch is obsolete and back up any work before removing or renaming a local ref. The local branch commands in the branch deletion guide explain how to check before deleting.

Step 4: Retry and verify the repository

Once the active operation, stale lock, or confirmed ref conflict is resolved, retry the original command. Then inspect the working tree and branch state:

git status
git branch -avv

If the error persists, keep the complete error output and note the exact ref path it names. Avoid repeated cleanup attempts: the path and wording are useful clues for a maintainer diagnosing the repository state.

Git cannot lock ref FAQ

Can I delete every .lock file in .git?

No. A lock may belong to a Git process that is currently writing. Check for active operations first, then inspect the specific path in the error and remove only a confirmed stale lock.

Does git fetch --prune delete remote branches?

No. Pruning removes local remote-tracking references for branches that no longer exist on the remote. It does not delete branches from GitHub or another remote server.