Worktrunk：让 Claude Code 并行管理 Git worktree
Worktrunk 给并行运行 Claude Code 的开发者管理 Git worktree，用 wt 命令替代繁琐的路径切换。
GitHub max-sixty/worktrunk 更新 2026-09-13 分支 main 星标 7.2K 分叉 256
Rust Git worktree AI agent CLI macOS/Linux/Windows

🧭 决策指南

为什么现在热： README 将 Worktrunk 描述为面向并行 AI agent 的 Git worktree CLI，并展示 Claude Code、Codex、Hooks、LLM commit messages 和 wt merge 等工作流；结合 2026-09-13 当日新增 54 星、总计 7,236 星以及最新版本 0.77.0，材料支持“并行 AI 编码工作流受到关注”这一解释，但无法仅凭材料确认具体上榜原因。

适合，如果你

  • 你要让 Claude Code 或 Codex 同时处理 5-10+ 个任务。
    README 的“Context: git worktrees”写明 AI agents 可并行管理 5-10+ 个任务，并以 Claude Code 和 Codex 为例。
  • 你希望用 wt merge 一条命令完成 squash、rebase、merge 和清理。
    README 的“Merge workflow”和“Quick start”展示了 wt merge main 的本地合并与 worktree 清理流程。
  • 你需要为每个 worktree 自动安装依赖或启动 dev server。
    README 的“Hooks”说明可在 create、pre-merge、post-merge 等阶段运行命令；“post-start hooks”示例提到安装依赖和启动服务。
  • 你的项目在 APFS、btrfs 或 XFS 上有多个大型构建目录。
    README 的“Share build caches”说明十个 worktree 可共享 target/、node_modules/ 等缓存而无需构建或复制。

不适合，如果你

  • 你只需要一个 worktree，并不使用 Claude Code、Codex 或并行 agent。
    README 将核心场景定义为“running AI agents in parallel”，并以 5-10+ 个 agent 解释 worktree 价值。
  • 你的团队不能接受具体许可证仍显示为 Other。
    项目基础信息中的许可协议为 Other，提供材料未给出具体许可证名称。
  • 你依赖 Windows Terminal 的 wt 命令别名且不想改用 git-wt。
    README 的“Install”说明 Windows 下 Winget 会安装 git-wt 以避免 Windows Terminal 命令冲突。

前置条件

  • 项目需要 Git worktree；README 的“Context: git worktrees”以 Git 原生 worktree 为基础。
  • macOS 或 Linux 可使用 `brew install worktrunk && wt config shell install`。
  • Cargo 安装路径为 `cargo install worktrunk && wt config shell install`。
  • Windows 的 Winget 安装路径为 `winget install max-sixty.worktrunk`，随后使用 `git-wt config shell install`。
  • 运行 shell integration 测试需要 bash、zsh、fish、nushell、pwsh 和 jq。
  • 共享构建缓存章节明确列出 APFS、btrfs 和 XFS。

第一步命令（README 原文）

brew install worktrunk && wt config shell install

要注意

  • Windows 下可能需要使用 git-wt，而不是 wt。
    README 的“Windows”安装说明指出 Windows Terminal 的命令冲突会导致 Winget 安装 git-wt。
  • shell integration 会改变目录，因此安装后需要执行 wt config shell install。
    README 的“Install”说明 Shell integration allows commands to change directories，并在 Homebrew、Cargo 等命令后执行该安装命令。
  • 并行 agent 的独立目录不等于独立端口，端口需配置 hash_port。
    README 的“Dev server per worktree”说明 hash_port template filter 才会为每个 worktree 提供唯一端口。
  • 测试 shell integration 不能只安装默认 shell，还需要 jq。
    README 的“Running the tests”明确列出 bash、zsh、fish、nushell、pwsh 和 jq。

替代方案

  • Git 原生 worktree：只需要 `git worktree add`、切换目录和 `git worktree remove`，不需要 wt 的 Hooks、AI 摘要或合并工作流时更直接。
    README 的“Context: git worktrees”与“Worktrunk makes git worktrees as easy as branches”
  • Claude Code 原生 worktree 工作流：团队只围绕 Claude Code 的官方工作方式运行，不需要 `wt list`、`wt merge` 或多种 shell 集成时更简洁。
    README 的“Further reading”与“Claude Code integration”

材料未说明

  • README 提供材料没有说明具体许可证名称及其商业使用条件。
  • README 提供材料没有给出支持的 Git、Rust、Node.js 或操作系统版本。
  • README 提供材料没有量化 wt 相比 Git 原生命令的性能或磁盘节省。
  • README 提供材料没有说明 LLM commit messages 支持哪些模型或需要哪些凭据。
  • README 提供材料没有说明 CI 状态支持哪些 CI 服务。
  • README 提供材料没有说明 10 位贡献者之外的维护分工和响应时效。
  • README 提供材料没有给出与其他 Git worktree manager 的对比数据。
  • README 提供材料没有说明 hooks 失败时的回滚行为。

💡 深度解析

6
适合 我正在维护这个 Rust CLI，需要验证 bash、zsh、fish、nushell 和 pwsh 的 Shell 集成，并且可以安装 jq；README 是否给出了可直接执行的测试入口？
适合读者： 维护 Rust CLI、希望在 bash、zsh、fish、nushell 和 pwsh 上运行 Shell 集成测试的项目贡献者

适合，README 直接给出了 Rust 测试和 Shell 集成测试命令，并明确列出所需 Shell 与 jq。

  • 项目主要使用 Rust 实现，项目数据中的 Rust 代码量为 9,847,106，cargo test 是 README 提供的基础测试入口。
  • Shell 集成测试的命令是 cargo test --test integration --features shell-integration-tests，不是需要自行拼接的参数组合。
  • README 明确要求 bash、zsh、fish、nushell、pwsh 以及 jq，因此你的测试环境约束与文档描述完全匹配。
  • 这验证的是项目的测试套件和 Shell 行为，不代表所有业务项目的 hooks、端口模板或自定义 aliases 都会自动通过测试；那些配置仍属于项目使用者自己的工作流。

对于贡献者，这是清晰的起点；如果 CI 机器缺少任一 Shell 或 jq，README 没有提供安装矩阵。

  • Running the tests：`cargo test`
  • Running the tests：`cargo test --test integration --features shell-integration-tests`
  • 原句：The shell integration tests need bash, zsh, fish, nushell, and pwsh, plus `jq`
  • 项目核心数据：main_language 为 Rust；Rust 代码量为 9847106
cargo test --test integration --features shell-integration-tests
材料未说明：README 未说明各 Shell 的最低版本和测试运行所需的操作系统组合。；README 未说明 CI 中是否会自动安装 `jq` 及这些 Shell。；README 未说明测试套件对自定义 hooks、aliases 和项目级模板的覆盖程度。
适合 我需要同时启动 3 个 Claude Code 任务，分别处理认证、分页缺陷和 API 测试，并且不能让未提交修改互相覆盖；Worktrunk 是否适合？
适合读者： 同时运行 Claude Code 代理、需要并行处理 3 个独立任务的个人开发者

适合，因为它直接把 Git worktree 隔离和 Claude 启动整合进同一条命令。

  • wt switch -x claude -c feature-a -- 'Add user authentication' 会创建独立分支和 worktree，并在切换后启动 Claude；README 明确说明 -- 后的参数会传给代理。
  • 三个任务可以分别使用 feature-a、feature-b、feature-c，每个代理拥有独立目录，避免未提交文件和构建产物直接覆盖。
  • wt list 会集中显示当前 worktree、修改状态、相对 main 的领先关系和远程推送状态，便于查看代理进度。
  • 完成后可以走 PR 清理，或用 wt merge main 执行提交、变基、合并和清理。

但目录隔离不保证三个任务在逻辑上没有冲突；如果它们修改同一接口，仍需处理合并冲突。

  • Quick start：`wt switch -x claude -c feature-a -- 'Add user authentication'`
  • Quick start：`-x` flag runs a command after switching; arguments after `--` are passed to it
  • Quick start：`wt list` 展示 worktree 状态、领先关系和远程状态
  • Workflow automation：Merge workflow — squash, rebase, merge, clean up in one command
wt switch -x claude -c feature-a -- 'Add user authentication'
材料未说明：README 未说明同时运行 3 个 Claude 进程时的 CPU、内存或 API 配额要求。；README 未说明代理同时修改相同文件时是否有额外的冲突检测或协调机制。
适合 我在 Windows 上使用 Windows Terminal，并希望用 Claude Code 创建和切换 Git worktree；由于 `wt` 已被终端命令占用，我是否应该安装 Worktrunk？
适合读者： 在 Windows 上使用 Windows Terminal、需要管理 Claude Code worktree 的开发者

适合，但应使用 README 为 Windows 冲突提供的 git-wt 入口，而不是直接假设 wt 可用。

  • README 明确指出 Windows Terminal 已占用 wt，因此 Winget 会额外以 git-wt 安装 Worktrunk，避免命令冲突。
  • 对应安装命令是 winget install max-sixty.worktrunk，安装后用 git-wt config shell install 配置 Shell 集成；这一步负责让切换命令能够改变当前目录。
  • 如果你关闭 Windows Terminal 的应用执行别名，也可以直接使用 wt，但 README 将其列为替代路径，不是默认路径。
  • 安装后仍可使用 -x 启动 Claude，并用 git-wt list 查看多个 worktree；Worktrunk 的核心功能仍建立在 Git worktree 上。

因此，Windows Terminal 并不是阻断条件，真正需要确认的是团队是否接受 git-wt 命令和对应的 Shell 集成方式。

  • Install：Windows 上 `wt` defaults to Windows Terminal's command
  • 原句：Winget additionally installs Worktrunk as `git-wt` to avoid the conflict
  • Windows 安装命令：`winget install max-sixty.worktrunk`
  • Windows 安装章节：`git-wt config shell install`
winget install max-sixty.worktrunk
材料未说明：README 未说明 Windows 上具体 Shell（PowerShell、pwsh 或其他）的完整兼容矩阵。；README 未说明 `git-wt` 与现有 Git aliases、企业设备策略或受限 Winget 环境的冲突情况。
适合 我通过 GitHub PR 合并多个 feature 分支，希望在一个列表里看到哪些 worktree 有未提交修改、哪些提交尚未推送以及 CI 状态；Worktrunk 是否能替代手工逐个检查？
适合读者： 采用 GitHub PR 流程、需要同时维护多个 feature 分支并查看 CI 状态的工程团队成员

适合，因为 wt list --full 正是为多 worktree 状态汇总设计的，但它不会替代 GitHub 的审查和合并权限流程。

  • Quick start 的 wt list 展示工作区修改、相对 main 的领先提交、远程推送状态、提交信息和年龄；这覆盖了你需要的本地分支概览。
  • README 进一步列出 wt list --full 的 CI status 和 AI-generated summaries per branch，因此可在列表中查看更完整的分支信息。
  • PR workflow 支持先 gh pr create，再通过 GitHub/GitLab 合并，最后执行 wt remove 清理；工具不会把 PR 审查过程替换掉。
  • 还可以使用 wt switch pr:123 直接跳到 PR 对应分支，减少按路径查找 worktree 的操作。

所以它适合减少状态巡检和清理工作；若团队需要复杂的审查规则、权限控制或 CI 修复，它仍依赖 GitHub 和现有工程流程。

  • Quick start：`wt list` 展示 Status、HEAD±、main↕、Remote⇅、Commit、Age
  • Expand into the more advanced commands：`wt list --full` — CI status and AI-generated summaries per branch
  • PR workflow：`gh pr create` 与 `wt remove`
  • 原句：`wt switch pr:123` to jump straight to a PR's branch
wt list --full
材料未说明：README 未说明 CI 状态支持哪些具体 CI 平台、认证方式和失败状态刷新频率。；README 未说明 GitHub/GitLab 私有实例、代理网络或细粒度权限下的 PR/MR 兼容范围。
视情况 我需要让每个 worktree 使用独立开发服务器端口，并在创建 worktree 后自动安装依赖和启动服务；Worktrunk 是否能覆盖这套 Shell hooks 流程？
适合读者： 需要为每个 worktree 启动独立开发服务器、使用 Shell hooks 自动安装依赖的高级命令行开发者

视情况，因为 Worktrunk 提供端口模板和创建后 hooks，但 README 没有把完整的依赖、数据库和服务生命周期配置打包成默认方案。

  • 高级功能明确提供 Dev server per worktree，并指出 hash_port template filter 可为每个 worktree 生成唯一端口。
  • Hooks 支持在 create、pre-merge、post-merge 等阶段运行命令，Quick start 还明确举例可用 post-start hooks 安装依赖和启动开发服务器。
  • 路径模板、aliases 和 per-branch variables 可以把分支状态传给 hook 模板，适合把端口、服务名或本地参数纳入项目规则。
  • 但 worktree 目录隔离不等于数据库、容器或外部服务隔离；README 只说明自动化入口，没有保证任意服务都能安全并行运行。

因此，纯开发服务器端口分配有明确支持；完整环境自动化是否可行，取决于你的 Shell 命令、依赖管理器和运行时资源。

  • Expand into the more advanced commands：Dev server per worktree
  • 原句：`hash_port` template filter gives each worktree a unique port
  • Workflow automation：Hooks — run commands on create, pre-merge, post-merge, etc
  • Quick start：Configure post-start hooks to automate setup (install deps, start dev servers)
wt config shell install
材料未说明：README 未给出 `hash_port` 的模板语法、端口范围或端口冲突处理行为。；README 未说明 hooks 在命令失败、重复创建 worktree 或清理阶段的退出码与回滚行为。；README 未说明数据库、容器和外部服务是否有内置隔离机制。
视情况 我在 macOS 的 APFS 上同时维护 10 个 worktree，希望复用 Rust 的 `target/` 和 Node.js 的 `node_modules/`，减少重复构建和安装；Worktrunk 能否满足？
适合读者： 维护 macOS 项目、需要在 10 个 worktree 中复用 target/ 与 node_modules/ 的 Rust/Node.js 开发者

视情况，因为 README 明确支持这类缓存复用，但只承诺特定文件系统和被忽略目录场景。

  • README 的高级功能列出 Share build caches，说明 10 个 worktree 可以获得 target/、node_modules/ 等目录，而不必重复构建或复制。
  • 支持范围明确包含 APFS；因此 macOS APFS 是项目文档直接覆盖的环境，不需要把需求降级为普通目录复制。
  • 该能力属于 wt step copy-ignored 相关工作流，不等同于所有构建系统都能安全共享缓存；缓存内容、锁文件和工具链兼容性仍可能决定结果。
  • hooks 可以在创建 worktree 时自动安装依赖或准备环境，但 README 没有承诺 Rust 与 Node.js 项目的具体配置会自动生成。

如果你的目标只是减少重复安装，它值得采用；如果不同分支会产生不兼容依赖，README 没有足够信息保证共享目录安全。

  • Expand into the more advanced commands as needed：Share build caches
  • 原句：ten worktrees get `target/`, `node_modules/`, etc without building or copying them
  • 原句：on APFS, btrfs, and XFS
  • Workflow automation：Hooks — run commands on create, pre-merge, post-merge, etc
brew install worktrunk && wt config shell install
材料未说明：README 未说明 Rust target 缓存或 Node.js node_modules 在不同分支依赖变化时的失效与清理规则。；README 未说明 `wt step copy-ignored` 对具体构建工具、包管理器和符号链接的兼容边界。

✨ 核心亮点

  • 支持 5-10+ 个 AI agent 并行工作树
  • wt merge 一条命令完成合并与清理
  • Hooks 可自动安装依赖和启动服务
  • APFS、btrfs、XFS 可共享构建缓存
  • 贡献者仅 10 人，已发布 5 个版本

🔧 工程化

  • wt switch、list、merge 三个核心命令管理工作树
  • wt list --full 展示 CI 状态和 AI 摘要
  • wt switch pr:123 可直接切换到 PR 分支
  • hash_port 为每个 worktree 分配独立端口

⚠️ 风险

  • 许可证元数据为 Other，具体许可未说明
  • Windows Terminal 别名会使命令改用 git-wt
  • shell integration 测试要求五种 shell 和 jq
  • README 称其最流行，但缺少外部对比数据

👥 适合谁？

  • 同时运行 Claude Code 或 Codex 的开发者
  • 需要管理 5-10+ 个 Git worktree 的团队
  • 使用 Rust、Node.js 或多端口开发服务的项目
  • 需要 Hooks 自动化依赖和服务启动的开发者