多 AI 会话共用仓库，提交前查清暂存区

三个 AI 会话共用一个 Git 工作目录，其中一个完成任务，你看过 diff，顺手提交，却把另外两个会话的改动一起带走了。作者在开源项目 KeelBase 的日常协作中踩过这种坑：提交说明写的是自己完成的任务，提交内容却越过了任务边界。

这篇文章提醒我们：AI 写完代码之后，人接手的第一步往往是提交，而提交需要单独审查。理解暂存区、识别共享文件、检查最终提交，比看到测试通过就放心更重要。不过，原文部分命令缺少参数，也有需要澄清的 Git 语义，不能直接照抄。

为什么看过 diff，提交还是会混进别人的代码

作者有一次修改路线图，提交前执行了：

git status --short | head -3

它想解决的问题是快速查看工作区状态。需要盯住的是 head -3：它只显示前三行，无法证明后面没有其他改动。

结果，这次提交还带上了另一个会话留下的三个 cherry-pick 标记，以及第三条工作流的两条状态记录。原文没有进一步解释标记的具体内容，但问题很清楚：需要检查的是完整范围，截断输出却把判断依据删掉了。换成 head -20，也只是把遗漏的边界往后移。

Git 里至少要分清三个位置：工作区是当前磁盘上的文件，暂存区（index）保存准备提交的内容，提交则是已经记录下来的快照。

不带路径的普通提交，提交的是整个暂存区。

你刚才编辑了哪些文件，并不能限定这次提交。另一个会话提前暂存的内容，也可能一起进入提交。而 git add -A 会广泛收集新增、修改和删除；同一个文件里其他会话尚未提交的行，也会随整份文件进入暂存区。

所以，风险有两个方向：你可能提交别人的改动，你新建的未跟踪文件也可能被别人的 git add -A 收进去。作者列出的四类误收场景，并不是四次独立实验，原文还重复刊登了相关段落，阅读时不必把重复内容算成额外证据。

限定文件只是第一步，共享文件还要检查到行

作者建议提交时明确列出路径，并在提交前后各检查一次。原文给出的最小自查是：

git diff --cached --name-only # only your files
git commit -F msg.txt -- a.ts b.ts
git show --stat HEAD # only your files

这三行分别检查暂存文件、限定提交路径、查看最终提交范围。需要特别看第二行：-F 必须放在 -- 前面，后面才是路径。

但这里有两个边界。第一，原文另一个示例是 git commit -F msg.txt -- .，其中 . 覆盖当前目录范围，不能达到逐个列出 a.ts b.ts 那样的精度。第二，带路径的 git commit 会采用指定路径的工作区内容，不能简单理解为只从现有暂存区里挑文件。因此，前面的暂存文件清单，并不能替代对目标文件内容的检查。

同文件并发修改更麻烦。作者曾打算在表格末尾增加一行，直接追加后暂存整个文件，结果提交带入其他三个会话的七行新增、三行删除。发现时，别人已经在这个提交之上又提交了两次。

针对路线图、认领表、执行日志这类多人频繁重写的文件，作者采用了备份工作区、恢复到 HEAD、只插入自己的修改、检查后提交、再恢复备份的做法。它的目的，是先拼出一份只包含当前任务的文件版本。

这套操作依赖协作纪律。如果其他会话在备份和恢复之间继续写文件，旧备份就可能覆盖新内容。原文没有说明如何暂停并发写入，也没有提供自动保护机制。

哪些检查能证明提交正确，哪些不能

提交之后 git status 干净，只能说明相关状态没有待处理差异，不能证明刚才提交的内容符合任务意图。作者建议用 git show --stat HEAD 再看一次范围；如果几个任务共用同一文件，还需要继续阅读实际 diff。

旧版本读取也容易混淆。作者警告，恢复旧内容的操作可能改写暂存区，随后提交就会产生内容回退，而测试读取的工作区仍可能看起来正常。

不过，原文把 git checkout -- 的影响概括得过宽：是否更新暂存区，要看有没有指定提交或树。它列出的 git checkout HEAD -- 属于从 HEAD 恢复的形式，但还缺少路径。原文的 git show : 同样不完整；冒号前后需要补齐要读取的版本与路径，不能原样执行。

历史检查也有类似问题。git log -1 能打印某个提交，不足以证明它仍在当前主线上；作者提出用祖先关系判断，但写出的 git merge-base --is-ancestor HEAD 缺少另一个待比较的提交。

还有提交钩子。即使手动提交限定了路径，post-commit hook 若继续执行不带路径的 git commit --amend，仍可能重新提交整个暂存区。修复范围因此也包括工具链。

我的判断

我赞同作者把「提交范围」单独拿出来审查。文件能运行、测试通过，都无法回答「这些改动是否属于当前任务」。原文最有价值的证据，是作者明确记录了自己的失误，而不是泛泛要求大家小心。

但这是一套经验之谈。文章没有提供执行规则前后的误提交率，也没有和独立目录、Git worktree 等隔离方式做对照。对一般团队来说，让每个 AI 会话拥有独立工作目录，通常更容易建立清晰边界；代价是需要另外处理集成和共享环境。

共享目录下的备份恢复流程可以应急，却不能仅靠几条命令保证并发安全。尤其原文用 git diff -- 检查「是否只暂存了自己的行」，语义并不准确：它默认检查工作区与暂存区之间的差异，检查暂存内容应使用 git diff --cached。

误收发生后，也别直接复制作者用过的 git reset --soft HEAD^。作者确实用它拆过一次提交，并表示没有丢内容，但另一例已经有人继续提交，处理条件完全不同。原文用于追查的 git log -1 --format=%h -- 和 git show --stat 示例也缺少具体路径或提交对象，需要先补齐上下文。

能拿来做什么

• 多个 AI 会话同时修改前端或 Node 项目时，优先分配独立工作目录；必须共用目录时，先约定共享文件的写入时段。
• 提交前完整检查 git diff --cached --name-only，再阅读相关 diff；同一文件混有多个任务时，把审查粒度缩小到具体修改行。
• 提交后检查 git show --stat HEAD 和实际补丁，同时查看提交钩子是否执行 git commit --amend，确认自动步骤没有扩大范围。
• 发现误收后先定位提交、核对内容是否仍在，再判断是否需要拆分；已有其他工作接续的历史，不要默认重写。