用途
并发分支（concurrent-branches）用于解决同一仓库同时存在多个开放分支时的冲突与合并问题。其核心观察是：当多个分支并行推进时，冲突往往不落在开发者以为的业务代码上，而是落在几乎每次改动都必须触碰的一小撮「热点文件」上，例如注册表清单（registry manifest）、版本字段、共享工具配置、单个聚合测试模块、被跟踪的构建产物等。每一类热点都有且只有一种正确的解决方式，且规则各不相同；任选一侧几乎都不是正确答案，更糟的是一旦选错往往悄无声息——丢失的条目、撞车的版本号、过期的构建包都可能「绿色合并」，直到后来某个人无法复现问题时才被发现。
主要能力
该技能按热点类型给出处理规则：
- 事先找出热点文件：通过
git log --format= --name-only -n 200 | sort | uniq -c | sort -rn | head -15列出最常被触碰的文件，形成热点清单，并把每类文件的解决规则写入贡献文档。 - 可累加注册表：取并集，绝不二选一：当清单列出所有组件（插件条目、模块路径、导出名、特性列表）时，两个分支各自追加条目，合并时应保留双方全部条目。若取单侧，会删掉一个仍然完整存在于代码树中的组件——代码能编译、测试能过，但该组件永远不会被注册或安装。可通过把注册表与文件系统双向校验来发现，例如用
jq -r '.plugins[].components[]' manifest.json检查每个注册路径是否存在，再遍历components/*/检查磁盘上的每个组件是否已注册，并把它作为仓库测试而非合并当天的临时动作。 - 单值计数器：从集成分支重新计算：版本字段、序列号、「最新迁移」指针等，两个分支都从 2.17.0 升到 2.18.0 时双方都已过时，因为第三个分支早已合并。此时并集没有意义，选边会重新引入撞车，正确做法是从当前集成分支重新计算，例如
git show origin/main:manifest.json | jq -r '.metadata.version'后由本分支取 2.19.0。该操作应在推送前最后一步执行，而不是在合并过程中。 - 生成产物：重新构建，绝不合并：提交进仓库的压缩包、构建出的 PDF、编译后的 schema、签入的快照等，其唯一正确内容就是由合并后的源文件生成的结果。应先解决源文件冲突，例如
git checkout --merge -- src/ ui/app.jsx，再make build重新生成，最后git add dist/bundle.js docs/handbook.pdf加回。为便于审查，需固定生成器版本，使输出在任何环境字节一致，便于评审者重新生成并比对；同时只校验预期区域发生变化——重建文档会重排，一段修改通常扩散到两三个连续页面，可用光栅差分或与基于基线提交构建的版本比对，并在 PR 中说明哪些区域变化及原因。 - 非确定性序列化：排序后再写出：若被跟踪文件由遍历顺序不稳定的 map、set 或 dict 写出，则每次运行都会整文件重写，导致每个分支每一行都冲突，差异无法审查，真实冲突被淹没。应在写出前排序，例如用
sorted((to_record(k, v) for k, v in index.items()), key=lambda r: r["date"])；文中说明 ISO-8601 日期作为普通字符串即可按时间排序，无需解析。该规则适用于任何从无序集合重建已提交文件的代码路径，包括日后新增的路径。 - 共享工具配置：取基础文件，重放你的增量：对 pyproject.toml、package.json、lint 配置、CI 工作流等文件，应先整体取集成分支的副本（
git checkout origin/main -- pyproject.toml），再只重新加入本分支新增的行，之后git diff origin/main -- pyproject.toml应只显示你的新增内容。若 diff 中出现某处固定版本被回退或某工具段落消失，说明误选了一侧。 - 聚合测试模块：保留两套用例并检查遮蔽：两个分支向同一测试文件追加用例时应取并集，但并集可能产生同名测试，在 Python 和 JavaScript 中后定义者会直接覆盖先定义者，文件看起来更长、用例数看似合理，实际有一个分支的用例从未运行。可用
grep -oE ... | sort | uniq -d查找重复测试名。同类问题也会出现在生产代码中：两个分支各自新增同名模块级辅助函数，合并后第二个会遮蔽第一个。 - 共享标识符：只追加，绝不重编号：对带有稳定标识符的仓库（来源台账中的 claim ID、迁移号、fixture key、快照名），为腾出编号而重排（如把 C7–C12 重编号）是一次干净无冲突却会破坏所有引用的修改，那些引用位于本次合并未触及的文件中。新增标识符应延续现有最大编号，且不得复用或重编号；若两个分支都占了 C17，应改自己的编号并修正自己的引用，而不是改动已合并的一侧。
- 干净的自动合并不等于验证通过：两个分支编辑同一大文件的相隔较远区域时可无冲突合并，但语义上仍可能出错：一侧的改动依赖另一侧已删除的辅助函数，或双方以不同名字加入了等价逻辑，或一侧的改动落入另一侧已设为不可达的分支。非平凡合并后，应确认双方都存活，例如分别
git grep -n "computes the retry budget"与git grep -n "REDACTION_PLACEHOLDER"查找各自独有的字符串，确认其不仅存在而且一致，再一起阅读这两处区域。 - 匹配仓库集成风格，并重新运行真实门禁：用
git log --graph --oneline -20判断历史使用合并提交还是线性变基，并沿用现有做法。推送前应在本地运行仓库真正的 CI 命令：已解决的合并是一段从未在任何地方存在过的代码，两个分支各自的 CI 运行都未覆盖它，本分支绿灯与 main 绿灯都无法说明其并集正确。
使用方式
该技能以命令与代码示例给出可操作步骤，涵盖热点识别、注册表并集、版本重算、产物重建、序列化排序、配置重放、测试去重、标识符追加、合并后双向校验以及本地 CI 运行等环节，并附有一份清单，逐项列出：分支前用 git log --name-only 识别热点文件；注册表/清单冲突按并集解决并保留双方条目；在 CI 中双向校验注册表与文件系统；版本/计数字段从 origin/main 重算而非取自任一侧；生成产物由合并后的源文件重建，不做文本或二进制合并；固定生成器版本以便评审者重新生成并比对；由 map/set 序列化的文件按稳定键排序；共享工具配置取自基础并重放增量，使 git diff 只显示自己的行；合并后的测试模块检查重复测试名；新增共享标识符只追加，不复用不重编号；在合并后的代码树中能找到来自双方的独有字符串；推送前在本地对合并结果运行仓库真实 CI 门禁。
适用场景
适用于多人或多分支并行开发同一仓库、需要频繁合并的场景，尤其是存在注册表清单、版本字段、共享配置、聚合测试、构建产物等热点文件的仓库。
限制
资料未说明该技能的安装方式、支持平台或运行环境要求。相关延伸主题在原文中以链接形式提及（如 reproducing-ci-locally、shipping-build-artifacts、improving-python-code-quality、shipping-across-surfaces），其具体内容未在本文档中展开。