七个人同时改一个仓库不撞车：我的多会话并行开发协议

问题：多个 AI 会话同时开发同一个仓库，怎么不互相踩？

我用 Claude Code / Codex 跑多个会话并行开发同一个 git 仓库，一开始觉得「各开各的分支就行」。直到有一天：两个轨道抢了同一个决策编号、四个轨道同时编辑共享账本文件导致合并冲突、git add -A 把另一个轨道的四个未提交文件扫进了我的提交、有人问了一个三小时前就已经解决过的问题——因为没看最新状态。

那一天的记录：7 个同时运行的 worktree，8 个合并的 PR，6 次不同性质的撞车。

parallel-sessions-protocol 就是从事故报告里长出来的协议。

机制一：开工先登记（公告板）

写任何代码之前：

1. git fetch origin + gh pr list --state open — 先看完整公告板。
2. 从最新 origin/main 切分支；每个会话占一个独占工作目录（主 checkout 也算一个，任何时刻最多一个会话拥有它）。
3. 立刻开一个 draft PR，body 固定三段：

- Claimed scope — 本轨道要改的目录/文件 - Claimed numbers — 占用的顺序资源（migration/决策编号…），没有写 none - Current status — 一行，里程碑时更新

4. 轨道结束（合并或放弃）时 PR 关闭，公告板自清洁。

公告板 就是 gh pr list。后台/派生会话遵守同一规则。

机制二：用前先认领

机制三：记账只在合并前写

共享账本文件（current-task / decisions / changelog 类）是并行轨道「构造性撞车」的重灾区：

1. 轨道活着的时候绝不碰共享账本文件。过程笔记放在轨道自己的文件里——零冲突。
2. 合并前的最后一步：rebase 到最新 main，然后追加账本条目（append-only 文件加在末尾；newest-first 文件插在顶部），然后立即请求合并。
3. 合并是串行的，所以账本写入也串行——冲突从「必然」变成「罕见」。
4. 万一还是冲突：唯一正确解法是 两边全保留。 dropping 任一边都会抹掉另一轨道的记录。

机制四：合并纪律

• 合并必须串行；谁可以合什么，按项目自己的规则（有些项目允许文档类 PR 自合并，查 AGENTS.md/CLAUDE.md）。
• 永远本地预览后再合并：git merge origin/main --no-commit --no-ff。GitHub 的 MERGEABLE flag 落后于最新 main，曾验证过「显示 CLEAN 实际冲突」的情况。
• 永远不要在 main 分支上停放 worktree——它阻塞所有其他需要 checkout main 的操作。
• **绝不 git add -A**；永远显式 add 路径。 blanket add 会把其他轨道的未提交文件扫进你的提交，而且如果内容恰好匹配 main，你根本发现不了。
• rebase 后 push 用 --force-with-lease（plain push 会被拒；plain --force 可能毁掉并发更新）。

机制五：三时点刷新 + CI 扫一眼

在工作开始时、向 owner 提问/报告重大结论前、合并前，各跑一次 git fetch + gh pr list（约 30 秒）。

工作开始时顺便扫一眼 CI：gh run list --limit 5。如果 main 是红的，先报告再开工——一次红的 cron 曾连续跑了 45 次失败、四天没人发现，因为每个会话都以为另一个人在盯着。

机制六：收工登记

会话暂停/中断，但轨道还活着时：

1. Push 或声明。未合并工作推到轨道自己的分支；不能 push 时在 draft PR 里写 WIP 声明。
2. 工作区卫生。用完移除 worktree；必须留着时，在 PR 里记录原因。孤儿 worktree 会静默累积。
3. 刷新公告板。更新 draft PR 的 Current status。
4. 关闭已触发事项。任何 pending-verification / ledger entry 的触发条件已满足的，现在关闭——不是「稍后」。

真实事故 vs 杀死它的机制

安装方式

bash git clone https://github.com/laojin1900/365Skill.git ./install.sh parallel-sessions-protocol

仓库链接：github.com/laojin1900/365Skill/tree/main/skills/parallel-sessions-protocol