“地址已被锁定”错误源于服务端 ref 锁文件残留，非本地问题；需登录 Git 服务器检查并安全删除 .git/refs/heads/xxx.lock 等残留锁文件，确认无并发操作、磁盘空间充足且无僵死 git 进程后执行清理。
远程分支“地址已被锁定”不是本地问题，而是服务端 ref 锁残留导致的拒绝操作，不能靠 git pull 或 git reset 解决。
为什么 git push --delete 报 “remote ref is locked”
这个错误明确指向 Git 服务端（GitLab / Gitea / 自建 SSH 仓库）在更新引用时卡在锁文件未清理阶段。典型触发场景包括：
- 前一次
git push因网络中断、SSH 超时或进程崩溃而中止 - 多用户并发推送同一分支（尤其在 CI/CD 高频触发时）
- 服务端磁盘满、权限异常或 Git 后端进程僵死
关键线索是错误里带 cannot lock ref 'refs/heads/xxx' —— 这和本地 .git/index.lock 完全无关，别去删自己电脑上的 .git 目录。
如何确认是服务端锁残留
直接登录 Git 服务器（SSH），进入仓库的 .git 目录，运行：
find . -name "*.lock" -o -name "packed-refs.lock"
常见残留锁路径有：
.git/refs/heads/feature/login.lock.git/packed-refs.lock.git/objects/incoming-*.lock
如果发现任一文件存在且修改时间早于最近一次正常操作，基本可断定是它堵住了。
服务端手动清理锁文件的注意事项
删锁文件本身简单，但必须满足三个前提才安全：
- 确认当前没有其他人在执行
git push、git fetch或 CI 流水线写入该仓库 - 确保仓库所在磁盘还有足够空间（
df -h检查） - 检查 Git 进程是否存活：
ps aux | grep git，若有疑似僵死的git-receive-pack进程，需kill掉
清理命令示例（以删除分支锁为例）：
rm -f .git/refs/heads/feature/login.lock
注意：不要用 rm -rf .git/refs/heads/，只删具体 .lock 文件；删完立即测试 git push origin --delete feature/login 是否恢复。
团队协作中容易被忽略的复杂点
锁问题常被误判为权限或网络问题，真正麻烦的是它不报错在客户端——比如某次 git push --force 看似成功，但服务端实际卡在重命名阶段，只留下一个没删的 .lock，后续所有操作都静默失败。更隐蔽的是，某些 Git 托管平台（如旧版 Gitea）会在锁残留时返回 200 状态码却跳过写入，导致数据丢失而不提示。所以一旦遇到“删不掉分支”“推不上去但没报错”，第一反应应是登服务器看锁，而不是反复重试或换网络。
