claude-code-merge-queue: 本地零成本并行合并队列
Show HN: A local merge queue for parallel Claude Code agents
claude-code-merge-queue 是一个专为 Claude Code 智能体设计的本地合并队列工具。它通过序列化多个智能体的提交、构建和测试流程，有效避免了并行操作引发的推送冲突、重复构建以及测试不稳定性。与 GitHub 的合并队列不同，该工具完全在本地运行，零成本且无需创建 Pull Request，支持任何私有仓库。开发者只需简单配置，即可让智能体自动排队合并代码，同时保留清晰的历史记录，是提升 AI 辅助开发效率的利器。
同样的理念——序列化合并、合并前测试、保持历史整洁——但在你自己的机器上运行，而非在别人的计费云端。
HN 评论区
22- dpc_01234
SelfCI: https://radicle.network/nodes/radicle.dpc.pw/rad:z2tDzYbAXxT...，支持 git 和 jj。
- barrkel
是个不错的点子，不过在我看来，其中很大一部分原因是 git 本身的局限性。你看过 jj 吗？
我用 jj 配合每个子代理一个工作区（workspace），体验比用 git 和 worktrees 好多了。
当然，在更新 master 分支指针时保留 CI 门禁还是有用的，但一旦切换到 jj，你基本上就不再需要和分支打交道了。
- throwaw12
这个想法看起来不错，但能分享一下你是如何实现每天推送 90 个 commit 的工作流吗？
我理解每个 commit 的大小可能不同，但我猜你的 commit 等同于 Pull Request（因为你需要这个持续的合并队列来 rebase、merge 和测试），而且每个 commit 大概在 40-80 行代码（增删量）左右。另外，你很可能没有进行代码审查，因为以这个速度，哪怕每个 commit 只需要 2 分钟审查，也意味着要连续审查 3 个小时。
如果你没有审查每一段代码，那你的 commit 可能只是些小改动，其中 10-20 个才构成一个 PR，那你又是如何同时维持多个项目的开发工作的呢？