git index.lock exists: Fix "Unable to create '.git/index.lock': File exists" + worktree collision recovery (2026)

Published March 1, 2026 · 8 min read

Intent match: this page is for failures like fatal: Unable to create '.git/index.lock': File exists and lock-plus-worktree collisions such as already checked out at <path> during reset, rebase, pull, or worktree operations.

Table of contents

  1. Symptom split: process lock vs stale lock vs worktree collision
  2. Safe remediation order
  3. Worktree collision recovery branch
  4. Force-push avoidance notes
  5. FAQ

1. Symptom split before you touch lock files

Do not jump straight to deleting .git/index.lock. classify the failure first:

Failure signal Likely cause Correct branch
Unable to create '.git/index.lock': File exists while another Git command is active Legitimate active process lock Wait/terminate process, then retry original command
Same lock error after crash/terminal close Stale lock file left behind Verify no active process, remove stale lock, validate repo state
Lock error plus already checked out at <path> or branch ownership errors Stale lock + worktree metadata collision Clear lock first, then reconcile worktree ownership

2. Safe remediation order (do not reorder)

This order prevents accidental data loss and avoids false recovery signals.

# A) Inspect process + lock state
ps -ef | rg "[g]it"
ls -la .git/index.lock

# B) Capture branch + status snapshot before cleanup
git status -sb
git branch -vv

# C) If NO git process is active, remove stale lock
rm -f .git/index.lock

# D) Re-run the original command once
git status -sb
Do not delete index.lock while a real Git process is still writing. That can corrupt in-progress index operations.

If lock removal resolves the error fully, continue normal workflow. If the next error is branch/worktree ownership, continue to the collision branch below.

3. Worktree collision branch: lock fixed, branch still blocked

After clearing stale lock state, use this sequence for worktree collisions:

# 1) map branch ownership
git worktree list --porcelain

# 2) clear stale linked-worktree metadata if path was removed manually
git worktree prune
git worktree list --porcelain

# 3) if old worktree still exists and is no longer needed
git worktree remove /path/to/old-worktree

# 4) recreate/attach safely
git worktree add ../new-worktree your-branch

If you need a deeper branch-lock diagnosis, use Git worktree branch locked decision guide and git worktree already checked out recovery.

4. Force-push avoidance notes after recovery

Lock/worktree recovery often tempts people to force-push immediately. Do this instead:

# refresh remote state first
git fetch origin

# classify branch relation
git log --oneline --left-right --graph origin/your-branch...HEAD

# integrate remote commits safely (policy dependent)
git rebase origin/your-branch
# or: git merge origin/your-branch

# push normally
git push origin your-branch
Force-with-lease is last resort, not first response. Use it only when history rewrite is intentional and branch ownership is clear.

For the full non-fast-forward decision branch, use git push rejected non-fast-forward recovery. For rewrite safeguards, see Git force-push safety checklist.

5. FAQ

Can stale index.lock appear even if no command seems running?

Yes. Interrupted terminals, killed editors, or crashed hooks can leave lock files. Verify processes first, then remove stale lock safely.

What if lock errors keep returning after I delete the lock file?

You likely still have an active process, permission issue, or hook repeatedly spawning Git. Re-check process list and hook scripts before repeating cleanup.

Is this related to non-fast-forward push rejection?

Sometimes. Lock/collision cleanup fixes local repo state; non-fast-forward rejection is a remote history relation issue that needs fetch + integrate + push strategy.