科技 · 实用指南
Git 提示 dubious ownership？先证明用户、路径所有者与信任作用域
不要直接设置 safe.directory=*；先审计实际 Git、系统身份、仓库真实路径与受保护配置，再做最小修复。
Git 的 dubious ownership 拒绝是安全边界，不只是权限小故障。最快且安全的处理方式，是先证明哪个 Git 进程、以哪个用户、拒绝了哪个真实路径。
本指南把异常所有者、启动身份、共享仓库与配置作用域分开，帮助你选择最小且可回滚的修复。
冻结失败现场
先复制完整 fatal 信息、被拒路径与原命令，再更改所有权或配置。记录故障来自终端、GUI、服务、容器、CI、WSL 还是 SSH；同一工作树会因 Git、用户、HOME 或配置栈不同而表现不同。
不要先做 chmod、递归 chown、重克隆或 safe.directory=*。先保存 git --version、启动器、被拒路径和系统身份，才能判断应修仓库、修调用者还是授予有意例外。
证明实际 Git 进程与用户
在失败环境中记录 command -v git 或 where.exe git、git --version、whoami、id、HOME 以及服务账户。若使用 sudo，同时记录 SUDO_UID；官方文档说明 sudo 启动的 Git 可能也信任该 UID。
GUI 尽量用其内置终端或日志取证。终端用户 A 写入的全局例外，GUI 用户 B 未必能看到；WSL 的 Linux Git 与 Windows Git 也是不同程序与配置。
不用 Git 核实仓库真实路径和所有者
直接使用错误中打印的路径，通过 realpath 或平台等价命令解析链接，再用 stat、ls -ld 或 Get-Acl 查看路径及父目录。若 Git 在 rev-parse 前就拒绝，不要依赖 Git 命令找路径。
比较实际所有者与预期运行模型。sudo clone 导致的 root 所有权，与共享服务仓库、UID 映射的 bind mount、NAS 或 WSL 路径不是同一问题；仅属于同一组也未必满足所有者检查。
检查 safe.directory 的来源与作用域
在同一失败环境执行 git config --show-origin --show-scope --get-all safe.directory，并分别检查全局和系统配置。safe.directory 只接受 system、global 或 command 这些受保护作用域，本地仓库配置不能自行声明可信。
例外可能因软链接拼法、另一个 HOME、客户端与 SSH 服务端不同而失效。先匹配错误中的真实路径和执行侧，再新增或修改条目。
选择最小修复分支
个人克隆只是所有者错误时，确认无共享服务影响后修正为预期用户。仓库确由其他可信用户拥有时，在失败 Git 实际读取的受保护作用域中加入一个精确绝对路径；无关用户尽量使用独立克隆。
把 safe.directory=* 视为完全退出检查，而不是诊断。不要用递归 chmod 替代所有权分析，也不要在未理解服务与回滚前 chown 共享、包管理或服务目录。
明确处理 GUI、WSL、容器与 CI 边界
终端正常而 GUI 失败时，对比 GUI 的 Git、用户、HOME 与配置来源。WSL 正常而 Windows Git 失败时，先决定哪个 Git 应负责工作流。容器和 CI 要在真实任务内核对 UID/GID、挂载所有者映射与工作区生命周期。
SSH 或服务端失败必须修服务端身份和路径；客户端全局配置不会影响远端 Git。每个分支最终都应得到明确所有者或一个精确可信路径，而不是全机通配符。
验证并保留回滚记录
在原环境重复原命令，再运行 git status 与同一路径发现流程的只读操作。重新显示配置来源和作用域，确认未让无关仓库变可信，也未从未审路径执行 hook 或本地配置。
记录旧所有者、新所有者或精确 safe.directory 值、配置文件、责任用户、原因与回滚命令。成功标准是目标调用者能使用目标仓库，同时其他位置仍保留所有权保护。
