max-sixty/worktrunk

如果你已经在同一个仓库里并行跑多个编程代理，又嫌原生 git worktree 操作麻烦，Worktrunk 值得花时间试试。它是在 Git 之上做的一层便利封装，并不引入新的版本控制模型。

解决什么问题

开发者想让五个编程代理同时改五个功能，又不想它们互相覆盖文件。Git 原生的 worktree 能做到，但用起来别扭：新建一个 worktree 要在路径里把分支名重复一遍，再手动 cd 进去。Worktrunk 保留同样的 worktree，但用分支名来指代，路径由可配置的模板生成。日常操作因此变成一条短命令创建或切换、一条命令查看所有 worktree 的状态、完成后再合并或删除。

有什么不同

它的核心设计是把分支名当作句柄，文件系统路径从配置推导。wt switch --create feature-auth 会建分支、建 worktree 并切换过去；wt list 展示每个 worktree 的暂存改动、领先 main 的提交、未推送提交和年龄；wt merge main 则在本地完成提交、变基和快进合并。命令行要能改变当前目录，靠的是 shell 集成，所以安装步骤里包含安装 shell 钩子，而不只是放一个二进制文件。

代价是它与 Git 约定和 shell 行为绑定较紧。Worktrunk 提供了钩子和可选的 LLM 生成提交信息等便利，但状态仍是普通的分支和 worktree，路径与命名由你配置的模板决定。并行代理本质仍是多个 Git 检出：每个都需要自己的目录，读懂 wt list 输出的状态列和符号仍然需要 Git 基础。项目也比较年轻，最可靠的依据是文档里明确写出的命令。

谁值得试

适合：在同一个仓库的多个分支上跑 Claude Code、Codex 等代理，希望更快创建 worktree、并在一处总览所有进行中工作的人。习惯在本地合并而非走 PR 的开发者，也能用上 wt merge 这条路径。不适合：一次只做一个分支的独立开发者，或团队已统一使用 IDE 的 Git 集成，多一层 CLI 收益有限。若流程依赖 GitHub 或 GitLab 的 PR，文档中的 PR 路径仍然是在 Worktrunk 命令之间调用 gh 或 glab。

使用条件与边界

你需要支持 worktree 的 Git，以及文档给出的任一安装途径：Homebrew、Cargo、Winget、Arch 包管理器或 Conda/Pixi。改变目录的命令依赖 shell 集成（wt config shell install），因此需要修改 shell 配置；Windows 上 Winget 会把可执行文件装成 git-wt，避免与 Windows Terminal 的 wt 别名冲突，README 也给出关闭该别名以继续使用 wt 的办法。

自动初始化的钩子和 LLM 提交信息是额外的配置步骤，后者应该还需要配置模型服务。仓库的测试套件在跑集成测试时需要 bash、zsh、fish、nushell 和 pwsh，以及 jq。日常维护就是普通的 Git 卫生：及时清理已合并分支、保持路径模板一致、推送前检查生成的提交信息内容。

HotRepo 点评

HotRepo 在 2026-10-24 记录到 9,454 星、当日 +31，2026-10-25 记录到 9,457 星、当日 +31，共两次出现在日榜上。这只是快照，不足以判断趋势；两个日期也无法判断热度能否持续。项目创建于 2025-10-17，约一年历史。采用前值得核对文档中的 Claude Code 集成以及 worktree 路径模板是否匹配你实际使用的工具。