lfs lock 是什么
git lfs lock 对不可合并的大文件（设计稿、三维模型、数据集）加锁，避免两人同时修改造成二进制冲突：被锁文件在服务端登记，列表可见，他人推送涉及该文件的改动会被拒绝。它是「协作约定 + 服务端校验」的组合，不是本地开关——托管平台未启用锁支持时，命令会报错或只在本地提示。适合强顺序修改的场景。
基本信息
| 加锁 | git lfs lock <文件> |
|---|---|
| 查看 | git lfs locks 列出当前锁与持有人 |
| 解锁 | git lfs unlock <文件>（--force 强解需权限） |
| 前提 | 服务端支持锁定（托管平台的 LFS 锁功能） |
| 拦截点 | 服务端：他人推送涉及已锁文件时被拒绝 |
| 边界 | 锁不阻止本地改动与提交，靠流程配合 |
典型使用场景
- 美术与设计协作：模型、贴图、排版文件两人同改必冲突，先锁后改
- 二进制数据集：不可合并的数据文件，改动前加锁是流程的一部分
- 发布素材：上线前锁定终版素材，防止被意外覆盖
- 排错撤锁：误锁或残留锁阻塞他人时，查看列表并解锁
- 新人培训：把锁流程写进协作规范，减少踩坑
- 超时治理：定期检查长时间未释放的锁并提醒
常用示例
常用示例
git lfs lock assets/model.fbx # 申请锁定，服务端登记持有人
git lfs locks # 查看当前锁列表
git lfs unlock assets/model.fbx # 修改完成后释放
git lfs unlock --force assets/model.fbx # 授权场景下强制解锁他人的锁状态与动作
| 状态 | 含义 | 动作 |
|---|---|---|
| 已锁 | 服务端登记持有人 | 他人推送被拒绝 |
| 正常释放 | 持有人完成修改 | git lfs unlock |
| 强制解锁 | 管理员处理残留锁 | git lfs unlock --force |
| 未启用支持 | 报错或仅本地提示 | 先检查托管平台配置 |
锁定是协作约定加服务端校验：已锁文件被他人推送会被拒绝，适合二进制的强顺序修改场景。
锁拦截的是推送而不是本地编辑：团队要养成「动手前先看锁、改完立刻解锁」的节奏，否则锁形同虚设。
长期不释放的锁要约定处理流程：提醒持有人、评估后用 --force 解锁，并把原因记录在工单里。