GitButler 并行 AI 智能体：多个分支，一个运行中的应用

GitButler 让并行工作的 AI 编程智能体在同一个工作目录中，把各自的修改保存在独立分支上，使兼容的变更能够在同一个本地应用中一起运行。其并行智能体文档明确介绍了共享依赖安装和开发服务器，同时分别提交各项任务变更的方式。

它的吸引力很直接：一个功能、一项无关的修复，以及另一个智能体的任务可以同时推进，而你能查看它们组合后的结果。智能体可以通过 CLI 处理版本控制操作，让开发者专注于确定方向和判断产品质量。

下一步机会是多人协同开发：多个人和多个智能体围绕持续更新的产品开展工作。难点在于，大家必须就“更新到最新”究竟指什么达成一致。当前文件、智能体掌握的当前信息，以及已经测试的集成状态，是三种不同的状态。

资料核查日期为 2026 年 10 月 8 日。以下命令依据当前官方文档编写，仅作示例，不是一次已执行的 GitButler 操作记录。建议的协作规则和验证矩阵属于 Wavect 的分析。“10x”提速和“100x”多人协作增益在文中作为体验说法和预测讨论，并非 Wavect 的实测结果。

GitButler 如何让多个分支在同一次构建中运行？

GitButler 将已应用的分支组合到同一份检出文件中，同时保留各分支独立的历史。其工作区分支文档解释了自动生成的 gitbutler/workspace 合并提交，以及普通 Git 工具所能看到的组合提交状态。

这并不意味着每个智能体都有独立的文件系统。它们看到的是相同的文件、依赖安装和生成产物。当客户筛选功能与一项无关的发票显示修复能够共存时，这很有用。如果两个智能体都要重写同一个共享类型，或生成同一个产物，就需要协调。

“同一个运行中的构建”指的是开发进程可以使用组合后的文件。它不保证每次文件更新都是原子的，也不保证热重载能处理所有修改，更不保证依赖或数据库状态变化永远不需要重启。我们的编程智能体多文件原子编辑指南解释了多个文件发生变化时，正在运行的读取方可能看到什么。

在 GitButler 管理的工作区中，应使用它提供的写入操作。把 gitbutler/workspace 当成普通功能分支并直接向其提交，不符合工具所维护的组织方式。

AI 智能体何时应该共享 GitButler 工作区，何时应该使用 worktree？

任务能够共享文件和运行时状态时，可以共享工作区；需要不兼容的检出状态或相互竞争的实现方案时，应使用独立 worktree。Git 官方的 worktree 文档介绍了多个工作树共享同一个仓库的方式，同时各自保留 HEAD 和索引等工作树专属状态。

Worktree 分离的是检出的文件。如果任务还需要隔离端口、数据库和外部资源，就必须另外配置。反过来，两个文件位于不同文件夹，也不能证明它们的修改彼此独立。共享数据结构、锁文件或迁移脚本都可能让任务产生依赖。

更广泛的仓库和环境准备决策，可参阅我们的面向 AI 编程智能体的 Git worktree 与 Jujutsu 对比指南。本文讨论的选择更具体：你需要一个组合后的本地应用，还是需要将工作中的变更放在物理分离的目录里？

智能体能不使用桌面应用，直接控制 GitButler 吗？

可以。GitButler 文档提供了通过 but CLI 驱动的智能体工作流。先阅读智能体设置指南。安装 CLI 后，在仓库目录中运行：

but agent setup
but status

向导可以安装技能、写入工作流指令，并在需要时初始化工作区模式。应审查它准备修改的范围和指令内容。技能教会智能体如何操作 GitButler；仓库权限与分支保护才负责限制访问能力。

接下来，就可以用自然语言描述目标。例如：

在 feature/customer-filter 分支上实现客户筛选功能。将无关修复单独处理。修改共享文件前，与另一个智能体协调。只提交本任务的变更，并报告分支基线和已经执行的检查。

这是一条建议的任务提示，不是特殊命令。智能体应把它转换为合适的操作。人工检查时，GitButler 的智能体工作审查流程支持 CLI、TUI 和桌面视图。

最容易犯的错误，是把另一个智能体的工作一起提交。当前 but commit 命令参考说明，默认行为会包含所有未提交变更。仅指定目标分支，并不意味着只选择该任务的修改。应通过位置参数中的变更 ID，明确选择所需文件或差异块。

下面的 ID 仅作示例。请用你当前命令输出中的 ID 替换 q3、w7 和 n2，并在继续操作前检查每项选择。GitButler 的 CLI ID 文档提醒，标识符可能随着工作区上下文变化而改变。

but diff
but commit -b feature/customer-filter -m "Add customer filter" q3 w7

but diff
but commit -b fix/invoice-display -m "Fix invoice display" n2

but status

这遵循了分支与提交教程中的选择性提交方式。如果指定的目标分支不存在，-b 会将其创建为并行分支。如果它已经存在但尚未应用，提交命令会拒绝该目标。应协调选择与写入操作，避免另一个写入方让你刚刚核查的内容失效。

多个智能体如何避免覆盖或混入彼此的修改？

分配分支之外，还需要明确共享文件的修改责任。为每项任务指定分支和工作范围。提前列出常见冲突点：路由表、共享类型、依赖清单、锁文件、迁移脚本和生成代码。

假设两个智能体在任何修改发生前，都读取了同一个文件。第二个智能体随后如果基于过期内容整体替换文件，就可能删除第一个智能体的修改，此时甚至还没有两份已保留的提交可供合并。分支标签不会让这种文件系统操作自动获得独占权。

我们建议让独立实现继续并行进行，同时指定一名协调智能体或开发者，负责会整体改变共享工作区的操作。应用或移除分支、更新目标分支、整理历史，以及进入冲突解决模式，都需要协调。这类协调也可以由智能体完成，不必把每个常规决策都交回给人。

编辑共享文件前，重新读取相关内容，并约定由谁负责修改。提交前，检查实际选中的差异。如果同伴修改了你的任务所依赖的接口，就应更新原有假设，并重新执行受影响的检查。这些是工作流建议，不代表 GitButler 会强制执行文件所有权规则，或自动刷新每个智能体的上下文。

为什么共享构建通过了，单个分支仍可能有问题？

组合构建成功，只能验证你实际运行的那个组合，不能证明每个分支都能独立工作。这就是文档所述隐性依赖风险在实践中的表现。

设想一个例子：分支 A 在 API 响应中增加预计交付时间；分支 B 增加一个读取该字段的徽标。两个分支都应用时，功能正常。如果 B 的审查和发布基于一个尚未包含 A 的目标分支，即使没有任何文本行冲突，徽标仍然可能出错。

如果这个依赖是有意设计的，就应明确声明。当前 but branch 命令参考介绍了通过 but branch new delivery-badge --above delivery-api 创建依赖分支的方法。如果 B 原本应该独立，就需要消除意外依赖，或调整交付计划。

应在合适的检出目录或 CI 环境中，对分支或分支栈进行隔离检查。如果其他智能体仍在编辑共享工作区，却不断从中移除分支，反而可能产生新的干扰。

GitHub 的合并队列文档体现了最后一种区别：必需检查针对最新目标分支与排队变更的集成结果运行。队列执行的是已配置的检查，不能证明那些检查从未覆盖的行为正确。

准确记录测试对象。如果智能体在测试期间继续修改文件，结果就可能覆盖一组混合状态。做出批准决定时，应使用稳定的候选版本；相关输入变化后，再重新验证。共享预览仍然可以提供快速反馈，同时审查证据应绑定到可复现的状态。

审查他人的分支时出现冲突，应该怎么办？

先区分能否合入目标分支，以及能否与当前工作区兼容。but branch list 和 but branch show BRANCH --check所描述的检查针对上游目标分支。能够合入该目标的分支，仍可能与本地已经应用的其他修改冲突。

开展可能扰动当前工作的审查前，应先约定分支组合并记录恢复点。操作日志命令参考介绍了 but oplog snapshot -m "Before branch review"。必要时，还应另外记录应用状态；版本控制检查点不是数据库备份。

冲突解决 CLI支持通过 --ai 采用 AI 辅助路径。文档还介绍了 but resolve conflicts 和 but resolve apply，可用于处理存在冲突的提交，而不进入冲突解决模式。

传统交互式路径的影响有所不同。变基与冲突指南说明，这条路径会暂时用存在冲突的提交替换组合后的检出内容。应考虑其他写入方和正在运行的应用，协调这一变化。不要假设所有冲突解决路径对工作区的影响都相同。

智能体可能很快就能解决简单的文本冲突，但“不到一分钟”的说法，不能证明结果保留了两项任务各自的意图。应审查变更后的接口、行为和生成产物，再执行相关的单独检查与集成检查。解决冲突的时间和验证结果的时间，是工作流中的两个独立部分。

GitButler 已经支持多人实时协同工作流了吗？

GitButler 已经支持通过远程分支开展协作，但本次核查的文档并未确认，所有参与者的未提交修改都能在一个始终同步的工作区中共享。Butler Flow介绍了如何将同事的远程分支与本地工作一起应用，提前检查集成效果，其中也包括并非通过 GitButler 创建的分支。

but pull 命令参考介绍了一项显式更新操作：获取远程变更，并将所有已应用分支变基到更新后的目标分支。but pull --check 可以预览更新。由于它可能影响共享工作状态，执行时应与正在工作的智能体协调。

多人协同是一个可信的发展方向。在 A 轮融资公告中，GitButler 描绘了这样的未来：更早发现与同事的冲突，在持续变化的分支上继续开发，并让智能体理解团队正在开展的工作。这是公开的产品愿景，并非对团队所期待的每一种同步行为作出发布承诺。

我们的判断是，下一个实质性进步将来自缩短这段距离：从同事完成一项有用变更，到其他人理解该变更并作出相应调整。共享代码只是其中一部分。共享哪个版本已通过审查、哪些内容仍属探索，以及为什么作出某个决定，同样不可缺少。

关于通过共享会话和组织上下文协作，可参阅我们的 Mosaic 共享智能体会话分析。同步对话和同步产品状态回答的是不同问题。

“所有人都处于最新状态”究竟需要什么？

有用的多人协同系统，需要区分当前文件、当前智能体上下文，以及当前已经验证的分支组合。这是我们建议用来评估这一理念的方法，不是对 GitButler 现有功能的描述。

自动同步应允许团队保留稳定的审查候选版本，同时在其他地方继续开发。审查者需要知道自己批准的是哪个版本；排查故障的开发者需要能够复现问题；同事应该可以拒绝加入一个探索性分支，同时继续访问已接受的工作。

依赖关系也必须随变更一同传递。如果 UI 分支依赖 API 分支，团队就应该在单独批准任一分支前看到这个关系。同伴修改 API 时，受影响的智能体需要知道为什么必须重新读取它，而不只是收到“某些文件发生了变化”的通知。

这才是“100x”愿景中有实质内容的目标：减少整个团队的协调等待，同时保持变更可理解、可测试。具体倍数和实现时间仍然只是预测。更多人或智能体同时编辑，本身不能证明会带来这样的提升。

团队应该如何验证开发提速的说法？

从一组规模小且有代表性的任务开始，衡量已被接受的工作和协调投入。尝试同时处理一个功能和一项独立修复。检查各个审查单元，让它们一起运行，再基于当前目标分支集成。随后用团队现有流程重复实验；如果独立 worktree 是合理备选，也应纳入比较。

使用可比任务，并记录任务复杂度、智能体与模型配置，以及审查者是否有空处理。跟踪从开始到变更可审查且已测试所需的时间、每项已接受变更消耗的审查分钟数、集成返工，以及只有在独立测试分支时才发现的故障。重试和修复产生的模型与基础设施成本也要计算。

个人报告的“10x”体验可以成为尝试的理由，却不能决定另一支团队会得到什么结果。改善可能来自环境准备步骤减少、上下文切换减少、组合反馈更快，或人工版本控制操作减少。在把全部收益归因于一个工具之前，应先确定实际改变的是哪些环节。

Wavect 的 AI 赋能服务可以帮助团队制定协作规则，并根据交付结果评估效果。我们的 Hyperstate AI 工程案例属于另一项独立产品合作，不能作为 GitButler 部署或提速基准的证据。

使用上线前软件 QA 检查清单明确验收标准，或讨论团队的并行智能体开发流程。请准备两项有代表性的任务、一次近期集成故障，以及目前采用的审查流程。