Git工作树偶发‘fatal: not a git repository’错误排查求助

• 排查Git自动清理机制的跨机器影响
  共享磁盘的.git目录被所有机器共享，若某台机器上的任务执行了git worktree prune，Git会检查对应工作树目录是否存在——但其他机器的工作树在本地磁盘，这台机器的Git无法识别，会误判该worktree已失效，从而删除.git/worktrees/xx目录。要检查所有任务中是否有触发git worktree prune的操作，包括隐式调用（比如某些Git命令会自动触发prune）。

• 核查Jenkins任务的异常清理逻辑
  确认任务的异常处理脚本没有遗漏：比如步骤失败后，清理代码是否误删了共享磁盘上的worktree记录目录；检查Jenkins的Workspace Cleanup插件或全局清理配置，是否误将共享磁盘的.git/worktrees路径纳入清理范围；同时查看任务的post-build步骤，有没有不管构建结果都执行的清理操作，导致目录被意外删除。

• 检查共享存储的稳定性
  查看系统日志（/var/log/syslog、dmesg），排查共享磁盘（如NFS/CIFS）是否出现过挂载断开、IO超时等异常——这类问题可能导致目录结构被破坏或意外删除。同时可以测试共享存储的读写稳定性，比如在多机器同时读写时，是否出现文件目录丢失的情况。

• 规避多任务并发的Git元数据冲突
  多个任务同时操作同一个仓库的.git目录时，可能触发Git内部的竞争条件，导致worktree记录被意外覆盖或删除。可以给操作仓库元数据的步骤加排他锁，比如用flock命令包裹关键Git操作：

  flock /data/repositories/foo/.git/worktrees.lock -c "git worktree add --no-checkout /path/to/worktree SHA1VALUE"
  

  确保同一时间只有一个任务修改.git/worktrees目录下的内容。

• 排查系统级临时文件清理进程
  检查系统中tmpwatch、systemd-tmpfiles-clean等清理服务的配置，确认它们的清理路径不包含/data/repositories/foo/.git/worktrees——这类服务可能会将未被识别的目录判定为临时文件删除。

• 增加日志和实时监控
  在任务关键步骤前后添加日志：

  • 步骤3创建worktree后，执行ls -ld /data/repositories/foo/.git/worktrees/xx并记录输出
  • 步骤7、9执行前，先判断目录是否存在，若不存在则输出当前机器ID、任务ID、同时运行的同仓库任务列表
    测试环境中可以用inotifywait监控目录删除事件，定位触发删除的进程：

  inotifywait -m -e delete,delete_self /data/repositories/foo/.git/worktrees/xx
  

内容的提问来源于stack exchange，提问作者ElpieKay