git index.lock 已存在速查：Unable to create 与六个根因

更新时间：2026-10-24。FAQ 速查页，面向 git add、git commit、git rebase 一跑就抛 fatal: Unable to create ... index.lock: File exists 的同学。git index.lock 已存在的含义一句话：git 任何要改写索引的操作都会先创建 .git/index.lock 占位、写完再原子改名替换真索引——锁在，说明「上一次有人要改索引」这件事没收尾；九成是上次 git 进程被杀或崩溃留下的残锁，删了就好，但删之前必须先确认没有活的 git 正在写，否则会把索引写成两半。收敛在六根轴上：崩溃/强杀留残锁、同一仓库并发跑两条 git 命令、IDE 或图形工具后台占锁、脚本与流水线抢锁、锁文件或 .git 目录权限异常导致删不掉、网络盘/共享目录的锁语义不可靠。本篇主线动作是「查活进程 → 无活进程才删锁」——顺序不能反。

本文要回答的问题

• Unable to create index.lock: File exists 到底能不能直接删？
• 怎么确认现在没有别的 git 正在写这个仓库？
• 为什么锁删掉了过一会儿又出现？
• IDE 开着的时候命令行 git 为什么总抢锁？
• 网络盘上的仓库为什么三天两头留锁？
• 删锁会不会把正在写的索引弄坏？

一、报错原文与典型现象

git index.lock 已存在家族的真实措辞如下（路径以 /proj/demo 占位）：

$ git -C /proj/demo add src/main.c
fatal: Unable to create '/proj/demo/.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. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

$ git -C /proj/demo commit -m "update"
fatal: Unable to create '/proj/demo/.git/index.lock': File exists.

$ rm /proj/demo/.git/index.lock
rm: cannot remove '/proj/demo/.git/index.lock': Permission denied

读报错抓三个信号：报错原文里 git 已经把处置流程写明白了——「先确认所有进程结束，还不行再手动删锁」，照做即可；报错重复出现且每次操作都撞，多半是有 IDE 或脚本在后台周期性占锁；删锁时 Permission denied 说明锁文件属主不对（之前用 sudo 跑过 git）或文件系统只读，这是另一类根因，删锁解决不了。

二、病因处置速查表

报错现象 / 场景	可能原因	快速验证	处置
报错一次、删锁即愈	上次 git 崩溃/强杀留残锁	看锁文件 mtime 是崩溃时刻	ps 确认无 git 后删锁
删了过会儿又出现	IDE/图形工具后台占锁	关掉 IDE 再观察	错峰操作或关 IDE 自动 fetch
流水线里偶发	两个作业并发跑同一仓库	看作业时间重叠	作业串行化或各用独立克隆
报错伴随 rebase 中断现场	rebase/cherry-pick 半途被杀	.git 下有 REBASE_HEAD 等	先 git rebase --abort 收尾再删锁
删锁报 Permission denied	锁属主是 root 或目录权限错	ls -la .git/index* 看属主	chown 回自己或 sudo 删
网络盘上反复留锁	锁语义不可靠/多机同挂	换本地盘不再现	仓库迁本地盘，禁多机同挂

三、排查决策图

下面这张图是标准排查路线，颜色按角色区分：红是报错入口与命中的根因，蓝是排查动作，绿是通过分支，橙是修复动作，紫是防复发沉淀。

读这张图抓主线顺序：第一步永远是查活进程而不是删锁——有活的 git 在写时删锁，等于两个人同时改一份索引，损坏比报错更麻烦；确认无活进程后，残锁删了无成本。删完还反复出现，根因就不在锁本身，要往并发、IDE 后台操作、权限、网络盘这四个方向找。

四、逐条排查展开

第一条：崩溃留残锁——最大宗，删了就好。 git commit 弹编辑器时 Ctrl+C、终端窗口被直接关掉、机器断电，都会让 index.lock 留下来。确认无活进程：

ps aux | grep -w git | grep -v grep

输出为空即可放心删：

rm /proj/demo/.git/index.lock

锁文件只是个空占位标记，删它不碰索引本体与任何提交。删完跑 git status 验证，状态正常即收工。

第二条：并发跑 git——同一时间两条命令抢一个索引。 一个终端在 git rebase（它会停在某一步等你处理，锁一直占着），另一个终端又 git add，必撞锁。判据：锁文件的 mtime 是「刚刚」，且 ps 里能看到活着的 git 进程。处置不是删锁，是让先来的跑完——或者去那个 rebase 的终端里 --continue / --abort 收尾。这和中断现场的收尾思路与 git rebase 冲突速查 里的状态机清理一致：先把进行中的操作结束掉，再谈下一步。

第三条：IDE 后台占锁——删了又来。 VS Code、JetBrains 系 IDE 的 Git 插件会周期性跑 git status、自动 fetch；你在命令行操作的一瞬间 IDE 恰好也在动，就撞锁。判据：锁反复出现、mtime 总是很近、关掉 IDE 就不再出现。处置：关掉 IDE 的自动 fetch 与自动刷新，或接受偶尔撞一次、重跑命令即可——这种撞锁是良性的，报错本身不会造成损坏。

第四条：脚本与流水线抢锁——偶发的真凶。 定时任务在跑 pull，部署脚本同时在 add/commit，偶发撞锁表现为「流水线偶尔红一次，重跑就好」。处置是架构级的：同一工作区的 git 写操作串行化（加文件锁或队列），或者干脆让每个作业用独立克隆。这类「偶发、重跑就好」的指纹与 git 钩子与 CI 偶发失败速查 里的并发互踩同源，别当一次性事故删锁了事。

第五条：权限异常——删都删不掉。 之前用 sudo git ... 跑过命令，留下的 index.lock 属主是 root，普通用户删不掉、也覆盖不了，于是所有 git 写操作永久卡死。验证：ls -la /proj/demo/.git/index*，看属主是不是 root。处置：chown 回自己，并顺带把整个 .git 目录属主检查一遍：

sudo chown -R $(id -un):$(id -gn) /proj/demo/.git

根因预防只有一句：永远不要用 sudo 跑 git。权限层的同类问题见 git 权限被拒速查。

第六条：网络盘与共享目录——锁语义不可靠。 NFS、SMB 挂载的目录上文件锁语义弱化，多机同挂一个仓库时 A 机的锁 B 机看不见，或者网络抖动让锁的创建与删除不可靠，表现为「锁删了又出现、还查不到活进程」。处置没有巧法：仓库迁回本地盘，网络盘只放备份；多人共享的裸仓库走 git push 协议层协作，不要直接共享工作区。

最后回答一个高频顾虑：删锁会不会弄坏正在写的索引？会——这正是先查活进程的原因。git 写索引的流程是「写 index.lock → 写完后改名覆盖 index」，在写的过程中删掉锁文件，对方改名时会拿到一个不属于它的文件状态，轻则报错重则索引内容截断。反过来，确认没有活进程后删一个残留的锁文件，风险为零：它不参与任何数据，只是个存在性标记。理解了这个机制，「先看进程、再删锁」就不再是口诀而是自然推论。

五、规范做法与预防

• 删锁前先查活进程：ps aux | grep -w git 为空才动手，这条顺序是铁律。
• 不并发跑同仓 git 写操作：终端里 rebase 没收尾，别开第二个终端动索引；流水线作业串行化。
• 永远不用 sudo 跑 git：属主污染是锁删不掉的最大根因。
• IDE 自动 fetch 按需关：频繁撞良性锁就关掉后台刷新，手动刷新更可控。
• 仓库放本地盘：网络盘只做备份与共享裸仓，工作区一律本地文件系统。

这一篇在知识体系里的位置

本篇是 Git 排错速查簇的并发与锁篇，定位「写索引时撞锁」：并发互踩的流水线偶发失败看 git 钩子与 CI 偶发失败速查；sudo 造成的属主污染看 git 权限被拒速查；锁文件写着写着盘满了看 git 磁盘写满速查；本批同簇的还有 git 提交时间作者不对速查；索引本身的概念见 add、commit、status。

一句话总结

git index.lock 已存在的本质是「上一次写索引没收尾」：先 ps 确认没有活的 git 在写，无活进程就直接删 .git/index.lock——它只是空占位；删了反复出现就往 IDE 后台操作、流水线并发、sudo 属主污染、网络盘锁语义四个方向归因。不并发动同一仓库、不用 sudo 跑 git、仓库放本地盘，这类故障基本绝迹。