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

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

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

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

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

为什么 AI 时代更需要 Worktree

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

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

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

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

• 当前目录只能对应一个分支，切来切去很容易打断思路

• stash 很脆弱，尤其是改动多、跨文件多的时候

• 不同任务的依赖状态、临时文件、实验代码容易互相污染

• 你很难让 AI 工具在多个任务上真正并行工作

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

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

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

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

Git Worktree 原生怎么用

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

而：

bashgit worktree add

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

例如：

bash# 主目录保持在 main git checkout main

新开一个 worktree

git worktree add ../dev-abc abc

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

• 当前目录仍然在 main

• ../dev-abc 目录在 abc 分支

几个常见场景：

并行开发

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

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

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

测完后清理

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

查看当前所有 worktree

bashgit worktree list

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

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

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

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

典型问题包括：

• 源码是检出来了，但依赖没装

• .env 没复制，项目跑不起来

• 每次都要自己决定 worktree 放在哪

• 分支和目录怎么命名，没有统一规则

• 任务做完以后，删除 worktree 和删分支是两套动作

• 手动删过目录后，Git 里还残留 stale worktree 引用

对前端项目尤其明显。

你执行了：

bashgit worktree add ../feature-a feature-a

然后进入目录，发现：

• node_modules 没有

• .env.local 没有

• 某些生成文件没准备

• 开发服务起不来

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

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

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

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

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

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

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

项目主页：

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

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

它的核心思路很简单：

• 你不再手动想路径

• 不再手动决定命名

• 不再手动 cd 进目标目录

• 不再每次都重复依赖安装和环境变量复制

• 不再手动分别清理 worktree 和 branch

你只需要输入一个命令：

bashccl

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

cc-launch 怎么工作

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

1. 创建新任务

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

• 输入任务名

• 自动把任务名转成安全的 slug

• 自动生成统一格式的分支名和目录名

• 选择基线分支

• 创建 worktree

• 执行该项目的 setup 脚本

• 进入目标目录，并可直接启动 codex 或 claude

例如你输入：

textfix login timeout

它会生成类似：

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

• 目录名：alice-fix-login-timeout

并统一放到：

text~/.worktrees//

下面。

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

2. 继续已有 worktree

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

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

3. 删除 worktree 或分支

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

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

• merged

• unmerged

• stale

你可以一次多选清理。

这意味着：

• 已合并的分支可以顺手清掉

• 未合并分支会明确提醒

• 那些目录已经没了、但 Git 还记着的 stale worktree 也能一并处理

它最关键的一点：setup 脚本

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

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

bash~/.worktrees//setup.sh

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

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

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

或者：

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

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

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

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

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

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

• 每个任务有独立的 AI 上下文

• 一个任务里的实验不影响另一个任务

• 可以同时开多个终端，让 AI 分别处理不同分支

• 修 bug、做 feature、验证历史版本可以并行发生

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

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

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

适合谁用

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

• 经常同时处理多个分支任务

• 不想再依赖 git stash 回切上下文

• 经常在 codex、claude 里开多个独立任务

• 想把 worktree 变成团队里的标准工作流

• 你的项目初始化步骤固定但重复，适合脚本化

快速上手

安装：

bashnpm install -g cc-launch

项目主页：

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

Zsh：

bashecho ‘eval “$(command ccl init zsh)”’ >> ~/.zshrc source ~/.zshrc

Bash：

bashecho ‘eval “$(command ccl init bash)”’ >> ~/.bashrc source ~/.bashrc

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

bashccl

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

text~/.worktrees//config.json

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

bashccl setup

最后

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

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

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

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