worktrunk 是一个用 Rust 写的命令行工具，专管 Git 的工作树。它把「新建一棵工作树、切过去、干完活合并、再清掉」这套动作压成几条命令，还可以按项目配置钩子，让新目录自动装依赖、起服务。项目自己在首页写得很直白：面向并行跑智能体的工作流。同时开三四个编码智能体改同一个仓库的人，最需要它。Windows、macOS 与 Linux 都能用，当前版本 0.81.0。

为什么工作树需要一条专门命令

Git 的工作树本来就不复杂：一个仓库可以同时检出多个分支到不同目录，互不干扰，也不必来回 stash。麻烦在操作。原生命令要记路径、记分支名，切过去还得自己 cd；目录攒到五六个之后，哪个分支改到哪一步、有没有落后主分支，全靠脑子记。

更现实的问题是智能体。让一个智能体在仓库里改代码，它会把工作目录弄成中间状态；再开第二个，两边互相踩。给每个智能体分一棵独立工作树是最干净的办法，可手工开树、手工收拾，一天下来光是管理目录就够烦。

wt switch：切的是目录，不是分支

wt switch 后面跟分支名，分支不存在就顺手建一棵工作树，已经存在就直接切过去。跟原生命令的差别在 shell 集成：安装完成后，切换会把终端的工作目录一起带过去，不用再敲一次 cd。它还能带一条命令一起跑，命令后面用双横线接参数，于是「建树 → 进目录 → 起智能体会话」能合成一步。

新树里的依赖和配置文件是空的，这由钩子补。项目级配置可以写好一段启动动作，比如装依赖、初始化数据库、起本地服务，每次开新树自动执行。钩子跑之前会问你要不要信任这个项目，避免 clone 下来一个仓库就替你执行命令。

wt list：一张表看清所有树

命令一行敲下去，出来的是表格。每一行对应一棵工作树，列出分支名、工作区状态、提交号、相对主分支领先或落后多少、与远端的差距、最后提交时间和提交信息。刚建好还没跑起来的树会标着加载中，几秒后补齐。

状态列

有未提交改动、有冲突、正在合并，都能在表里看出来，不必逐个目录去看

领先落后列

哪棵树落后主分支、哪棵已经推到远端，一眼扫完

提交信息列

配合自动生成的提交说明，看一行就知道这棵树在干什么

合并与清理，也有固定动作

干完活要收尾。wt merge 把当前树的改动提交、变基到目标分支、快进合并，然后把这个工作树和分支一起清掉，整个过程在后台完成，不打断你继续敲命令。它也支持生成合并提交，适合需要保留分支痕迹的仓库。

不想要了就 wt remove。被删掉的树不会立刻消失，而是先进 .git/wt/trash 这个回收位置，误删还有得救。攒久了用 prune 清理：分支已经合进默认分支的树会被删掉，没合并的、刚建不久的会跳过，还能设一个最小存活时间来控制尺度。

让每个智能体住进自己的目录

并行跑智能体时，最碍事的是那些被 git 忽略的文件：node_modules、构建产物、本地环境变量。新开一棵树，这些东西全是空的，智能体第一步就得花时间重装。wt 提供复制忽略文件的能力，把源树里这些目录搬过去，并对端口号、数据库名一类会打架的值做改写，让 2 棵树上的本地服务不会抢同一个端口。

worktrunk 的许可用的是 MIT 与 Apache 2.0 双许可，源码在 GitHub 上，文档站点也齐。它不绑定某一家智能体：任何能在终端里启动的编码工具，都能通过那条「带命令切换」的参数塞进新树里。

值不值得用

只维护 1 条分支的人不需要它，原生 git 够用。真正吃得上的是两类场景：同时推进几条互不相干的功能线，或者让两三个智能体并行改同一个仓库。前者省的是目录管理的时间，后者省的是互相覆盖之后的排查时间。

代价是要接受一层新的命令。wt 自己有一整套子命令与配置，钩子写错了也会让新树起不来；它还把 shell 集成当成前提，不装那一步，切换目录的体验就退回手工。

worktrunk 做的事情很小：把 Git 工作树从「知道有这么个功能」变成「每天都会用」。它没有发明新机制，只是把开树、看状态、合并、清理这四件事做成了顺手的命令，再加一层钩子让新目录能自己站起来。并行跑智能体的工作流里，这点顺手很值钱。