我以前同时开几个任务的时候，最怕的不是写代码，而是切分支。手头一个功能写到一半，线上突然要修个 bug，stash 一下、切过去、修完、再切回来、再把 stash 弹出来——每一步都小心翼翼，生怕哪一步手滑把没写完的东西弄丢。git worktree 本来就是为了解决这个问题的：同一个仓库可以在不同目录各检出一个分支，互不干扰。可惜原生用法实在别扭，新建一个 worktree 要把分支名敲三遍，路径还得自己记。worktrunk 就是把这层别扭磨平的工具：分支名就是地址，剩下的事它替你办。
它的核心命令只有三个，我上手十分钟就记住了。wt switch --create feature-auth，新分支、新目录、切过去，一步到位；wt list 一眼看清所有 worktree 各自改了什么、领先主分支几步、有没有没推的代码；干完了 wt merge main，把分支合回主分支，顺手把 worktree 和分支一起清掉。以前要敲一串 git worktree、cd、git branch -d 的活，现在一句话说完。对我来说，真正省事的不是少敲几个字符，而是脑子里不用再维护一张“哪个目录对应哪个分支”的表了。
这个工具最对我胃口的场景，是同时跑多个 AI 编程助手。以前我让两个 agent 各改各的，最担心的就是它们在同一个工作区里互相覆盖。给每个 agent 一个 worktree，问题就从根本上消失了：wt switch -x claude -c feature-a -- '加用户登录'，wt switch -x claude -c feature-b -- '修分页 bug'，三个任务各干各的，我再用 wt list 巡一圈，谁改了多少、谁跑偏了，一目了然。不用 agent 的时候也一样好用：手头功能做到一半，插进来一个紧急修复，开个新 worktree 就行，旧的现场原封不动地留在那里，等回来接着写。
还有几处小设计，我觉得是真正用过才懂的好。第一是钩子：worktree 建好之后自动装依赖、起开发服务器，这些重复活可以交给钩子，不用每个新目录手动来一遍。第二是构建缓存共享，十个 worktree 不用各复制一份 node_modules 或 target，省磁盘也省编译时间。第三是按分支给开发服务器分配不同端口的办法，每个 worktree 有自己的端口号，不用再为端口冲突改配置。第四是直接检出 PR 的分支，wt switch pr:123 就能跳过去看别人的改动，审代码的时候很顺手。
但有几个坑，我得提前说在前面，免得你装完第一天就骂它。最关键的一条：装完二进制还不算完，必须跑 wt config shell install 装 shell 集成。原因很简单，一个普通进程改不了父 shell 的当前目录，不装这层壳，wt switch 切了目录也不会跟着走，很多人第一次用就卡在这里。第二，Windows 上 wt 这个名字和 Windows Terminal 冲突，官方给的办法是装成 git-wt，别硬抢名字。第三，钩子虽好，但写错了会在每个新 worktree 里重复执行，调试时先在一个分支上试，别一上来就全量铺开。第四，构建缓存共享只在 APFS、btrfs、XFS 这类支持写时复制的文件系统上才有意义，别的文件系统上别指望它。第五，AI 生成的提交信息只是帮你起草，合并不检查就直接推，出了问题还是你自己的锅。
所以它适合谁？我觉得最适合三类人：已经在用 AI 编程助手、想同时跑好几个任务的人，这是它一开始就是为了解决的问题；经常被紧急修复打断、又不想 stash 来 stash 去的开发者；还有维护多个并行功能分支、需要一眼看清全局的团队成员。反过来，如果你平时一个仓库永远只用一个分支，从来不并行，那它对你就是多余的一层，不用硬上。先挑一个正在做的仓库装上，开两个 worktree 干一天活，合并不顺手再卸也不迟。
上手建议很简单：装好先跑 shell 集成，再在一个练手仓库里建个分支、改两行、wt list 看一眼、wt merge 合回去。这一圈走通了，你就知道它是不是你要的那种“少操心”的工具了。
