高效使用 Worktree，成为十倍程序员

Worktree 示意图

在 AI 参与开发之后，多任务并行已经不是少数人的工作方式，而是越来越常见的日常状态。

你可能一边在做一个新功能，一边要修线上 bug，还可能临时拉一个分支验证某个历史提交，或者开一个独立环境让 codex、claude 帮你处理另一个任务。这个时候，如果还用传统的 " 一个目录 + 来回切分支 " 的方式工作，很快就会被上下文切换拖慢。

这也是为什么，git worktree 在今天比过去更值得认真使用。

▲ Worktree 演示视频

1. 为什么 AI 时代更需要 Worktree

过去我们切任务，常见方式是：

git stash
git checkout main
git pull
git checkout -b fix-xxx

任务做完再切回来，git stash pop，继续原来的开发。

这套方式在“偶尔切一次任务”时还可以忍，但一旦同时处理两三个任务，问题就会很明显：

  • 当前目录只能对应一个分支，切来切去很容易打断思路
  • stash 很脆弱，尤其是改动多、跨文件多的时候
  • 不同任务的依赖状态、临时文件、实验代码容易互相污染
  • 你很难让 AI 工具在多个任务上真正并行工作

worktree 的价值在于：让一个仓库同时拥有多个独立工作目录，每个目录对应一个分支，各自互不干扰。

也就是说，你可以把“任务”直接映射成“目录”。

主目录继续停在 main 或 dev，另一个目录处理新功能，再开一个目录修 bug，互不影响。每个任务都有自己的终端、自己的 AI 会话、自己的文件上下文。

这比反复 checkout 更符合现在的开发节奏。

2. Git Worktree 原生怎么用

git checkout branchName 是在当前目录里切换到指定分支。

而：

git worktree add <path> <branch>

是把指定分支检出到一个新的目录。

例如：

# 主目录保持在 main
git checkout main

# 新开一个 worktree
git worktree add ../dev-abc abc

这样你就同时拥有两个工作区：

  • 当前目录仍然在 main
  • …/dev-abc 目录在 abc 分支

几个常见场景：

2.1. 并行开发

git checkout main
git worktree add ../feature-login feature-login
git worktree add ../fix-timeout fix-timeout

2.2. 快速拉起某个版本或提交验证问题

git worktree add ../test-v1.2.0 v1.2.0

2.3. 测完后清理

git worktree remove ../test-v1.2.0
rm -rf ../test-v1.2.0

2.4. 查看当前所有 worktree

git worktree list

从能力上说，worktree 已经很好了。

问题在于，它解决了“一个仓库多个工作目录”的问题，但没有解决“这些目录怎么真正变得可用”的问题。

3. 真正阻碍大家使用 Worktree 的，不是 Git，而是初始化成本

很多人第一次用 worktree 时都会觉得很惊艳；但真要长期使用，往往很快就会遇到现实摩擦。

典型问题包括：

  • 源码是检出来了，但依赖没装
  • .env 没复制，项目跑不起来
  • 每次都要自己决定 worktree 放在哪
  • 分支和目录怎么命名，没有统一规则
  • 任务做完以后，删除 worktree 和删分支是两套动作
  • 手动删过目录后，Git 里还残留 stale worktree 引用

对前端项目尤其明显。

你执行了：

git worktree add ../feature-a feature-a

然后进入目录，发现：

  • node_modules 没有
  • .env.local 没有
  • 某些生成文件没准备
  • 开发服务起不来

于是你还得继续手动做一串动作：

cd ../feature-a
pnpm install
cp ../main/.env.local .env.local
pnpm dev

如果每新建一个 worktree 都要重新做一遍，这件事就很难变成一个“顺手的日常习惯”。

所以多数人不是不会用 worktree，而是觉得它最后一公里太麻烦。

4. cc-launch 想解决的，就是这最后一公里

cc-launch 是我写的一个轻量 CLI，命令名是 ccl。

它不是为了替代 git worktree，而是把一整套零散动作收束成一个统一入口：创建、进入、清理 worktree，并在目标目录中继续工作或启动 AI 工具。

项目主页：

https://mogician.me/claude-code-launcher

如果你想先快速看一眼产品介绍、典型痛点和使用场景，可以直接打开这个页面。

它的核心思路很简单：

  • 你不再手动想路径
  • 不再手动决定命名
  • 不再手动 cd 进目标目录
  • 不再每次都重复依赖安装和环境变量复制
  • 不再手动分别清理 worktree 和 branch

你只需要输入一个命令：

ccl

然后按菜单选择接下来要做什么。

5. cc-launch 怎么工作

ccl 主要覆盖三类高频动作。

5.1. 创建新任务

当你要开始一个新任务时，ccl 会引导你：

  • 输入任务名
  • 自动把任务名转成安全的 slug
  • 自动生成统一格式的分支名和目录名
  • 选择基线分支
  • 创建 worktree
  • 执行该项目的 setup 脚本
  • 进入目标目录，并可直接启动 codex 或 claude

例如你输入：

fix login timeout

它会生成类似：

  • 分支名：alice/fix-login-timeout
  • 目录名：alice-fix-login-timeout

并统一放到：

~/.worktrees/<repo-name>/

下面。

这样所有项目的 worktree 都有固定位置，不会散落在各个奇怪目录里。

5.2. 继续已有 worktree

如果一个任务之前已经建好了，你不需要记路径，也不需要自己 cd。

ccl 会列出当前仓库的全部 worktree，包括主工作区。你选中一个，它就直接切过去，并按需启动 codex、claude，或者什么都不启动，只保留在该目录里。

5.3. 删除 worktree 或分支

这是很多人最容易拖着不清理的一步。

ccl 会把可以清理的 worktree 和 branch 放到同一个删除菜单里，并标记：

  • merged
  • unmerged
  • stale

你可以一次多选清理。

这意味着：

  • 已合并的分支可以顺手清掉
  • 未合并分支会明确提醒
  • 那些目录已经没了、但 Git 还记着的 stale worktree 也能一并处理

6. 它最关键的一点：setup 脚本

我认为这才是 cc-launch 真正让 worktree 变得“可日常使用”的关键。

ccl 支持为每个项目维护一个 setup 脚本，位置在：

~/.worktrees/<repo-name>/setup.sh

每次创建新的 worktree 后，这个脚本都会自动执行。

你可以把最烦、最重复、最容易忘的初始化动作全部放进去，例如：

#!/usr/bin/env bash
pnpm install
cp ../main/.env.local .env.local 2>/dev/null || true

或者：

#!/usr/bin/env bash
uv sync
cp ../main/.env .env 2>/dev/null || true

这样，git worktree 原本只负责“检出代码”，而 cc-launch 额外把“让这个目录能马上开始工作”也一起做了。

这就是它和单纯封装几个 Git 命令的区别。

7. 为什么这对 AI 工作流尤其重要

有了 AI 之后，我们对“工作区”的要求变了。

以前我们切目录，主要是为了人自己不混乱；现在我们还希望：

  • 每个任务有独立的 AI 上下文
  • 一个任务里的实验不影响另一个任务
  • 可以同时开多个终端，让 AI 分别处理不同分支
  • 修 bug、做 feature、验证历史版本可以并行发生

worktree 天然适合这种模式，但前提是创建和初始化不能太重。

如果每次新建工作区都要重新手搓一遍环境，那 AI 带来的并行能力很快会被流程摩擦抵消掉。

所以从这个角度看，cc-launch 其实不是单纯在优化 Git，而是在优化一种更适合 AI 协作的开发入口。

8. 适合谁用

如果你符合下面任意一种情况，这个工具大概率会有价值：

  • 经常同时处理多个分支任务
  • 不想再依赖 git stash 回切上下文
  • 经常在 codex、claude 里开多个独立任务
  • 想把 worktree 变成团队里的标准工作流
  • 你的项目初始化步骤固定但重复，适合脚本化

9. 快速上手

安装：

npm install -g cc-launch

项目主页：

https://mogician.me/claude-code-launcher

Zsh：

echo 'eval "$(command ccl init zsh)"' >> ~/.zshrc
source ~/.zshrc

Bash：

echo 'eval "$(command ccl init bash)"' >> ~/.bashrc
source ~/.bashrc

然后在任意 Git 仓库子目录运行：

ccl

首次运行时，工具会询问这个仓库的主分支，并把项目配置写到：

~/.worktrees/<repo-name>/config.json

如果你想为该项目补上自动初始化逻辑，可以执行：

ccl setup

10. 最后

git worktree 本身已经是一个很强的能力，但它离“高频、无脑、舒服地日常使用”之间，还差一层工程化包装。

而这层包装，恰恰决定了你会不会真的长期使用它。

cc-launch 想做的事情并不复杂：把路径管理、命名规范、环境初始化、目录切换、AI 启动和清理回收，统一收口到一个小而轻的 CLI 里。

如果你已经开始习惯让 AI 在多个任务上并行协作，那么 worktree 几乎是必备工具；而如果你觉得原生 worktree 好用但总差一点，cc-launch 解决的就是这一点。