我一开始用 Codex 做 AI 编程时最头疼的问题不是它写不出代码而是它一开跑就动我的 Git 分支。改到一半想并行处理另一个任务切分支怕冲突不切又怕把当前进度搞乱。后来我把 Git 的工作树Worktree和 Codex 配合起来用才真正解决了并行开发的痛点。这篇文章就专门讲讲 Worktree 和 Git 分支的关系以及如何把它用在 Codex 这种 AI 编程工具上。这篇内容适合正在用 Codex、Claude Code 这类 AI 编程工具做实际项目的开发者也适合对 Git Worktree 只停留在“听说过”阶段、想系统搞清楚原理的朋友。读完你会明白Worktree 不是用来替代分支的它恰恰是让分支真正发挥并行价值的基础设施。我会从原理讲到实操再附上我在真实项目里踩过的坑和排查思路。1. 内容整体设计与思路拆解1.1 为什么 AI 编程工具会放大 Git 分支管理的痛点先交代一个背景Codex 这类工具的工作方式和传统 IDE 补全完全不一样。它不是在你当前的编辑器里帮你补几行代码而是会自己读取整个仓库的上下文、创建多个文件、修改现有逻辑甚至跑测试来验证自己的改动。这意味着 Codex 每开始一个任务都相当于一个“不太受控的协作者”在你仓库里动手动脚。传统 Git 分支机制的设计初衷是让人手动切换上下文。你开发 feature A就切到 feature-A 分支开发 feature B再切到 feature-B 分支。但这个模型有一个隐藏成本切换分支时Git 会修改工作目录里的文件内容。如果你在 feature-A 分支上改了一半文件还没提交切到 feature-B 时就会报错或者被迫 stash或者直接因为冲突拒绝切换。用 Codex 时这个问题会被放大好几倍。我实测的场景是让 Codex 在分支 feature-A 上实现一个新 API 接口同时我自己想在 feature-B 分支上快速修一个紧急 bug。如果没有 Worktree要么我中断 Codex 的任务要么我把它改到一半的文件 stash 掉——但 Codex 的对话上下文是基于文件状态的它改到一半被 stash 走后续它再继续时看到的文件就是旧的上下文直接错乱了。所以这里要建立一个核心认知Git 分支解决的是“提交历史如何分叉”的问题Worktree 解决的是“多个分叉如何同时存在于磁盘上”的问题。分支决定代码逻辑往哪个方向发展Worktree 决定这些方向能不能在物理文件层面同时存在。1.2 方案选型为什么 Worktree 而不是 clone 多份仓库有人可能会说我不用 Worktree我直接把仓库 clone 到两个目录不也能并行开发吗确实可以这也是最容易想到的替代方案。但实际用下来有很明显的区别第一clone 多份仓库会丢失“单一工作区”的心理模型。你在第一个 clone 里提交的代码不会自动出现在第二个 clone 里。你得手动 push 到远端再到另一个目录 pull才能看到最新状态。Worktree 则共享同一个.git目录所有 worktree 的提交记录和分支引用都是同一个仓库里的天然同步。第二clone 多份仓库会带来身份认证、依赖安装、构建缓存的重复开销。尤其是 Node.js 项目每个目录都要重新npm install一次几百 MB 的 node_modules 占据大量磁盘空间。Worktree 虽然有各自的文件目录但你可以让多个 worktree 共享同一个 node_modules 软链接或者用 pnpm 这类支持全局存储的包管理器来避免重复安装。第三Worktree 是 Git 原生支持的机制配合git worktree list、git worktree remove这些命令管理起来很方便。而 clone 多份仓库你手写脚本去同步分支状态复杂度高、容易出错。当然 Worktree 也有缺点所有 worktree 共享同一个仓库如果有人不小心在一个 worktree 里执行了git gc或者git prune理论上会影响其他 worktree 的某些悬挂对象但实际极少发生。总体而言对 Codex 这种“需要多线并行、每线独立改动”的 AI 编程工具Worktree 是比多 clone 更合理的选择。2. Worktree 与 Git 分支的本质关系2.1 先用一个生活类比拆开“分支”和“工作树”很多人学 Git 时最容易混淆的概念就是把“分支”和“目录”绑在一起理解。我见过不少同学以为分支就是文件夹切分支就是换文件夹。这个理解在普通用法下勉强能通但遇到 Worktree 就会彻底懵掉。我用一个生活类比来说明。假设你在写一本书书稿放在书桌上。分支相当于你给书稿规划的“写作方向”有正稿主线、有实验性章节、有回炉重写的版本。工作树相当于你实际摊开在面前的那张稿纸。普通 Git 用法是你只有一张稿纸你写主线的时候就把稿纸清空重新铺写实验章节时又要清空再重新铺。同一时间只有一份稿纸摆在桌上。Worktree 相当于给你多买了几张书桌。每张书桌上摆着不同方向的稿纸主线方向的稿纸放在书桌 A实验性章节放在书桌 B。你在书桌 B 写实验章节时书桌 A 上的主线稿纸完全不受影响。但所有稿纸都属于同一本书都是这本书的写作计划的一部分。映射回 Git 概念这本书是整个仓库的.git目录每个分支是引用refs/heads/xxx每张书桌是一个 worktree桌上的稿纸是这个 worktree 的当前工作目录。分支是逻辑概念工作树是物理目录。2.2 Worktree 的命令模型从 add 到 remove 的完整理解理解 Worktree最核心的命令就五个# 创建一个新的 worktree 并关联到新分支 git worktree add ../my-feature -b feature/new-api # 在指定的提交上创建一个 detached HEAD 的 worktree git worktree add --detach ../my-experiment commit-id # 列出所有 worktree 及其关联的分支 git worktree list # 将某个 worktree 从仓库中移除 git worktree remove ../my-feature # 清理已经没有 worktree 的陈旧分支引用 git worktree prune这里有一个特别容易误解的点git worktree add的路径参数不是分支名而是“你想把目录建在哪个路径”。很多人第一次用写的是git worktree add feature/new-api结果它会在当前目录下创建一个名为 feature/new-api 的文件夹作为 worktree而不是把分支当作目录名。这个细节初看无所谓但对目录组织有强迫症的人很关键。关联关系上每个 worktree 有且仅有一个“当前检出的分支”。默认情况下Git 禁止在同一个仓库中两个不同的 worktree 同时检出同一个分支。如果你在 worktree A 上检出 dev 分支再到 worktree B 执行git checkout devGit 会直接报错。原因很简单如果两个目录同时检出同一个分支两边文件状态不一致commit 时无法确定“哪个是权威”。2.3 分支在 Worktree 中的存活与消亡规则还有一个容易被忽略的点Worktree 会不会因为分支被删除而自动消失答案是反过来——只要某个分支还有对应的 worktree这个分支就不能被删除。你执行git branch -D删一个有 worktree 的分支时Git 会拒绝操作提示你先git worktree remove或git worktree prune。这个规则实际用起来既保护了你也偶尔造成困惑。保护你是因为只要 worktree 存在分支上的提交就不会被任何清理操作误删。困惑是因为如果你建了一堆 worktree 忘了清理仓库会越来越“重”Git 的某些操作比如 checkout 其他仓库会因为这些锁定的分支而报错。我自己习惯的清理节奏是每轮 Codex 任务完成后确认改动已 push 到远端就立即git worktree remove删除对应目录。不要囤积 worktree它和临时分支一样都是短生命周期的产物。3. Codex 场景下 Worktree 的实操落地3.1 搭建“一仓库多 Codex 并行”的目录结构下面进入实际的方案。假设我有一个项目叫my-app当前在 main 分支上现在需要让 Codex 同时做两件事一个是实现用户认证模块另一个是重构数据库查询逻辑。第一步是建立两个 worktree 目录cd my-app git worktree add ../my-app-auth -b feature/auth git worktree add ../my-app-db -b refactor/db-query执行完之后磁盘上的结构是这样的my-app/ # 原来的主工作目录仍在 main 分支 my-app-auth/ # worktree检出 feature/auth my-app-db/ # worktree检出 refactor/db-query这三个目录共享同一个.git仓库所以我在 my-app-auth 里提交代码在 my-app 里执行git log --all立刻能看到新的提交。接下来就是重头戏让两个独立的 Codex 会话分别在两个 worktree 里跑。在终端 A 进入 my-app-auth启动 Codex在终端 B 进入 my-app-db启动另一个 Codex 会话。两个 Codex 都可以读取各自的目录、修改各自的文件、运行各自的测试互不干扰。cd ../my-app-auth codexcd ../my-app-db codex这一步的精髓在于Codex 的工作目录决定了它感知到的文件系统而 Worktree 给每个 Codex 会话提供了一个完全隔离的文件系统视角。同时两个会话又共享同一个仓库的 Git 历史——当你需要合并两边成果时在任意一个 worktree 里执行git merge都行。3.2 多 worktree 环境的依赖安装与复用策略Codex 要跑测试worktree 目录里必须能安装依赖。但每个 worktree 都装一遍完整依赖既费时又费空间。这里我实测过三种方案方案一npm 硬链接。npm 本身不直接支持跨目录共享 node_modules但你可以用ln -s把主目录的 node_modules 软链接到 worktree 里。问题是如果项目在构建时执行了删除 node_modules 或者修改依赖版本的操作软链接会失效Codex 可能会因为找不到模块而报错。这个方案适合纯阅读代码或轻量改动的场景不适合重度构建。方案二pnpm 全局存储。pnpm 默认把所有包的实体存储在全局 store 里各项目的 node_modules 只是硬链接所以即使每个 worktree 都单独执行pnpm install实际磁盘占用量也远远低于 npm。这个方案对 Codex 的干扰最小因为每个 worktree 看到的都是完整的、真实的 node_modules只是物理层共享了存储。我目前最推荐这个方案。方案三在 worktree 里直接复用主目录的依赖通过调整 NODE_PATH 环境变量实现。这个方案对多数现代打包工具webpack、vite不起作用因为它们不会去 NODE_PATH 找依赖所以这里只提一句不推荐深究。依赖装完后建议在每个 worktree 里都执行一次构建命令验证环境可用。Codex 这类工具在跑测试时如果第一步就报“模块找不到”它可能会在代码里私自加依赖、乱装包反而把项目搞乱。3.3 与 Codex 自动分支行为的配合方式这里补充一个我在实践中看到的细节Codex 有自动创建分支的行为。某些版本的 Codex CLI 在启动任务时如果检测到当前分支不是 main 或 master它可能会自己新开一个分支再开始改代码或者询问你是否要创建新分支。当你把 Codex 放在一个 worktree 里时它识别到的“当前分支”就是这个 worktree 检出的分支所有自动分支的逻辑都基于这个 worktree 展开。这就产生了一个协作模式你为每个 Codex 任务显式创建一个 worktree 加分支同时告诉 Codex 在现有分支上工作不要新建分支。这样整个工作流的责任边界非常清晰worktree 是物理隔离分支是逻辑隔离Codex 在隔离环境内自由发挥。# 在 worktree 里启动 Codex 时明确要求它不要更改分支 codex --skip-git-repo-check不过要注意--skip-git-repo-check这个参数在不同版本中行为有差异。早期的 Codex CLI 会检查当前目录是否是一个干净的 Git 仓库如果发现改动未提交会拒绝执行。在 worktree 中如果上一个任务留下了未提交改动你可能需要先git stash或手动提交一次再让 Codex 接着跑。4. 常见问题与排查技巧实录4.1 Worktree 被占用导致无法删除操作中我最常遇到的报错是这样的$ git worktree remove ../my-app-auth fatal: ../my-app-auth contains modified or untracked files, use --force to delete it这个报错的本质是worktree 里还有未提交的改动。Git 担心你删掉目录后这些改动永久丢失所以拒绝删除。你可能觉得“改动我不要了”于是直接加--forcegit worktree remove --force ../my-app-auth但我建议你先冷静一下。Codex 在 worktree 里跑过的任务可能留下了很多它自己创建的新文件、临时文件、日志文件。直接 force 删掉可能把某些想要保留的探索性代码一起丢掉。更稳妥的做法是先进入 worktree执行git status看清当前状态把值得保留的改动提交到分支再回到主目录执行git worktree remove删除目录最后需要清理分支时再执行git branch -D feature/auth。如果 codex 在 worktree 里创建的大量文件都是无用产物确实不想要再用 force 也不迟。总结一句话remove 之前先看清楚有什么避免误删有价值的内容。4.2 Codex 会话“看不到”其他 worktree 的改动这是 I 在并行开发中遇到的最诡异的情况我在 my-app-db 这个 worktree 里提交了重构代码然后跑到 my-app-auth 的 Codex 会话里问它数据库层的代码是什么样的它的回答还是老版本。原因是 Codex 在对话开始时对项目做了上下文快照。如果你在会话启动后修改了其他文件Codex 并不会实时感知。它只会根据它自己所在目录的最新文件状态以及 Git 历史中的提交记录来回答问题。因为 my-app-auth 这个 worktree 和 my-app-db 共享同一个仓库理论上 Codex 可以通过查看提交历史来感知 my-app-db 的最新改动但前提是 its 当前工作的分支能访问到 refactor/db-query 分支上的提交。解决这个问题的最好办法是让两个分支之间有明确的集成点。比如我在 my-app-auth 分支上工作但希望 Codex 能看到 refactor/db-query 的改动我可以用如下命令git fetch . refactor/db-query:refs/remotes/internal/db-query这个命令把本地仓库里的 refactor/db-query 分支引用复制到一个临时远端引用 internal/db-query这样 Codex 在查看历史时就能看到它。不过更简单的做法是你直接告诉 Codex去查看某个分支的最新提交它一般会执行git show或者git log来读取相关信息。如果 Codex 还是看不到就手动切到那个 worktree 目录把关键文件的路径告诉它。4.3 在 detached HEAD 的 worktree 里意外提交git worktree add --detach创建的 worktree 不关联任何分支。这种设计适合做实验、查历史、对比提交。但这个状态下如果 Codex 在 worktree 里改了代码并执行了git commit提交会落在“悬空提交”上不会出现在任何分支引用里。一个不小心你会发现提交在仓库里存在git log --all看不到任何分支 head 都指向不到它。好在 Git 的 reflog 会记录这个提交你可以通过git reflog找回。我的经验是不要让 Codex 在 detached HEAD 的 worktree 里做有目的性的开发。detached 状态只适合临时验证。如果一定要用就严格约束 Codex 不要执行 commit等确认无误后再在主分支上通过 cherry-pick 把这些临时提交摘出来。4.4 Windows 环境下路径与符号链接的坑Windows 上使用 Worktree 有几个独有的问题我提一下第一个是路径长度限制。Windows 默认最大路径 260 字符Worktree 通常建在仓库目录的兄弟位置路径长度会叠加项目名和分支名。如果项目名本身很长再加-b feature/xxx这种长分支名某些构建工具会直接报错。解决方式是开启 Windows 的 Long Path Support或者在创建 worktree 时选择短路径比如..\auth而不是..\my-app-auth-feature。第二个是符号链接权限问题。前面提到用软链接共享 node_modules在 Windows 上创建符号链接需要开发者模式或管理员权限。如果你没有这些权限ln -s会失败。建议在 Windows 上用 pnpm 代替手动软链接方案。第三个是 Codex CLI 在 Windows 上的 Git 识别问题。有次我在 Windows 的 worktree 目录里启动 Codex它提示“无法识别当前 Git 仓库”检查下来发现是 Codex 使用了内置的 Git 检测逻辑它对 Windows 的路径分隔符处理不够好。解决方法很粗暴在系统 PATH 中确保git.exe的路径排在所有 Git 相关工具之前让 Codex 能正确调用系统 Git。5. Worktree 管理习惯与 Codex 工作流整合5.1 以任务为单位的 worktree 生命周期管理聊完了原理和坑分享一下我目前稳定使用的管理流程。这里的核心思想是把 worktree 的生命周期绑定到单个 Codex 任务的生命周期而不是当长期存在的第二个工作区。我的一天大致是这样的早上从主仓库拉取最新 main 分支准备多个任务每个任务创建一个 worktreegit worktree add ../task-auth -b task/auth-login、git worktree add ../task-db -b task/db-index在终端里分别为每个 worktree 启动独立的 Codex 会话任务完成后进入 worktree 检查 Codex 生成的代码执行测试然后 commit 并 push回到主仓库执行git worktree remove清理目录执行git branch -d删除本地分支这样做的直接好处是主仓库目录始终干干净净永远停留在 main 分支上。我不用担心 Codex 把主工作区搞乱也不用在多个任务之间来回 stash。任务的隔离性非常强视觉上也很清晰——看到my-app-task-auth这个目录就知道 Codex 正在做 auth 相关的任务。5.2 用 Git alias 简化高频操作Worktree 的命令有点长经常敲路径容易累。我用几个 alias 减少了重复输入git config --global alias.wt worktree git config --global alias.wta worktree add git config --global alias.wtr worktree remove git config --global alias.wtl worktree list配置完之后创建 worktree 就是git wta ../task-auth -b task/auth-login删除 worktree 就是git wtr ../task-auth另外我还配了一个“创建 worktree 并进入目录”的函数直接在.bashrc或.zshrc里写function wt-add() { if [ $# -ne 2 ]; then echo Usage: wt-add path branch return 1 fi git worktree add $1 -b $2 cd $1 }这个函数省去了手动 cd 的步骤对频繁建 worktree 的 Codex 重度用户来说体验提升很大。5.3 多个 Codex 会话冲突的真正风险点最后想聊一个更深层的问题多个 Codex 会话并行时它们之间会不会真的“互相打架”答案是分情况。如果每个 Codex 会话只修改自己的工作树里的文件那它们完全隔离不会冲突。真正的风险在于 Codex 可能会主动读取 Git 仓库的全局状态比如git log --all、git branch -a。当两个会话同时执行这些命令时它们看到的分支列表是相同的如果其中一个会话擅自删除了另一个会话正在使用的分支就会出问题。比如 Codex 在 task-auth worktree 里跑着我手动删除了 task-auth 分支Git 会因为该分支还有关联的 worktree 而拒绝。但如果我用git worktree remove --force強制删除 worktree 后又用git branch -D删除了分支同时另一个 Codex 会话还在那个被删的 worktree 目录里继续开发它最后 commit 时就会丢失分支引用或者报错。解决策略还是那句话不要让 Codex 在同一个仓库的多个 worktree 之间交叉跳转。一个 Codex 会话负责一个 worktree目录边界就是责任边界。如果你希望两个任务之间有信息交换通过代码提交、message 传递而不是直接文件共享。5.4 后续扩展把 Worktree 写成自动化脚手架如果你已经适应了这套工作流下一步可以做点自动化写一个简单的脚本接收“任务名”参数自动创建以任务命名的 worktree、checkout 新分支、装入依赖然后启动 Codex。比如#!/bin/bash # codex-start.sh TASK_NAME$1 WORKTREE_PATH../cs-${TASK_NAME} BRANCH_NAMEcs/${TASK_NAME} git worktree add $WORKTREE_PATH -b $BRANCH_NAME cd $WORKTREE_PATH pnpm install codex这个脚本可以大幅降低你启动一个新任务的心理门槛。原来需要敲四五个命令现在一条命令搞定。依赖安装也放在脚本里避免 Codex 在后续执行中因为缺少模块而中断。6. 写在最后的经验与建议Worktree 这个东西实际上就是给 Git 分支的“多方向同时工作”提供物理层面的支持。没有它分支只能串行切换有了它分支才能真正并行推进。尤其是面对 Codex 这种 AI 编程工具它会频繁改动文件、可能中途出错、需要反复调整任务指令。没有隔离的工作环境AI 产生的混乱会直接蔓延到你的主工作区。我个人在实战中最大的体会是不要把 Worktree 当成一个“高级技巧”收藏起来它其实是每个 Codex 用户都该尽早纳入日常工作流的基础设施。它没有太多复杂概念核心就是 add、list、remove 三个命令。但就是这个简单的操作能让你的 AI 编程体验从“提心吊胆”变成“各司其职”。最后再分享一个小技巧如果你频繁使用 Codex 处理不同的任务建议把任务名作为分支名和 worktree 路径的统一前缀。比如所有 AI 相关的任务都用ai/开头这样一眼就能通过目录看清当前哪些工作是 AI 生成的哪些是你手动写的管理起来会清爽很多。
我一开始用 Codex 做 AI 编程时最头疼的问题不是它写不出代码而是它一开跑就动我的 Git 分支。改到一半想并行处理另一个任务切分支怕冲突不切又怕把当前进度搞乱。后来我把 Git 的工作树Worktree和 Codex 配合起来用才真正解决了并行开发的痛点。这篇文章就专门讲讲 Worktree 和 Git 分支的关系以及如何把它用在 Codex 这种 AI 编程工具上。这篇内容适合正在用 Codex、Claude Code 这类 AI 编程工具做实际项目的开发者也适合对 Git Worktree 只停留在“听说过”阶段、想系统搞清楚原理的朋友。读完你会明白Worktree 不是用来替代分支的它恰恰是让分支真正发挥并行价值的基础设施。我会从原理讲到实操再附上我在真实项目里踩过的坑和排查思路。1. 内容整体设计与思路拆解1.1 为什么 AI 编程工具会放大 Git 分支管理的痛点先交代一个背景Codex 这类工具的工作方式和传统 IDE 补全完全不一样。它不是在你当前的编辑器里帮你补几行代码而是会自己读取整个仓库的上下文、创建多个文件、修改现有逻辑甚至跑测试来验证自己的改动。这意味着 Codex 每开始一个任务都相当于一个“不太受控的协作者”在你仓库里动手动脚。传统 Git 分支机制的设计初衷是让人手动切换上下文。你开发 feature A就切到 feature-A 分支开发 feature B再切到 feature-B 分支。但这个模型有一个隐藏成本切换分支时Git 会修改工作目录里的文件内容。如果你在 feature-A 分支上改了一半文件还没提交切到 feature-B 时就会报错或者被迫 stash或者直接因为冲突拒绝切换。用 Codex 时这个问题会被放大好几倍。我实测的场景是让 Codex 在分支 feature-A 上实现一个新 API 接口同时我自己想在 feature-B 分支上快速修一个紧急 bug。如果没有 Worktree要么我中断 Codex 的任务要么我把它改到一半的文件 stash 掉——但 Codex 的对话上下文是基于文件状态的它改到一半被 stash 走后续它再继续时看到的文件就是旧的上下文直接错乱了。所以这里要建立一个核心认知Git 分支解决的是“提交历史如何分叉”的问题Worktree 解决的是“多个分叉如何同时存在于磁盘上”的问题。分支决定代码逻辑往哪个方向发展Worktree 决定这些方向能不能在物理文件层面同时存在。1.2 方案选型为什么 Worktree 而不是 clone 多份仓库有人可能会说我不用 Worktree我直接把仓库 clone 到两个目录不也能并行开发吗确实可以这也是最容易想到的替代方案。但实际用下来有很明显的区别第一clone 多份仓库会丢失“单一工作区”的心理模型。你在第一个 clone 里提交的代码不会自动出现在第二个 clone 里。你得手动 push 到远端再到另一个目录 pull才能看到最新状态。Worktree 则共享同一个.git目录所有 worktree 的提交记录和分支引用都是同一个仓库里的天然同步。第二clone 多份仓库会带来身份认证、依赖安装、构建缓存的重复开销。尤其是 Node.js 项目每个目录都要重新npm install一次几百 MB 的 node_modules 占据大量磁盘空间。Worktree 虽然有各自的文件目录但你可以让多个 worktree 共享同一个 node_modules 软链接或者用 pnpm 这类支持全局存储的包管理器来避免重复安装。第三Worktree 是 Git 原生支持的机制配合git worktree list、git worktree remove这些命令管理起来很方便。而 clone 多份仓库你手写脚本去同步分支状态复杂度高、容易出错。当然 Worktree 也有缺点所有 worktree 共享同一个仓库如果有人不小心在一个 worktree 里执行了git gc或者git prune理论上会影响其他 worktree 的某些悬挂对象但实际极少发生。总体而言对 Codex 这种“需要多线并行、每线独立改动”的 AI 编程工具Worktree 是比多 clone 更合理的选择。2. Worktree 与 Git 分支的本质关系2.1 先用一个生活类比拆开“分支”和“工作树”很多人学 Git 时最容易混淆的概念就是把“分支”和“目录”绑在一起理解。我见过不少同学以为分支就是文件夹切分支就是换文件夹。这个理解在普通用法下勉强能通但遇到 Worktree 就会彻底懵掉。我用一个生活类比来说明。假设你在写一本书书稿放在书桌上。分支相当于你给书稿规划的“写作方向”有正稿主线、有实验性章节、有回炉重写的版本。工作树相当于你实际摊开在面前的那张稿纸。普通 Git 用法是你只有一张稿纸你写主线的时候就把稿纸清空重新铺写实验章节时又要清空再重新铺。同一时间只有一份稿纸摆在桌上。Worktree 相当于给你多买了几张书桌。每张书桌上摆着不同方向的稿纸主线方向的稿纸放在书桌 A实验性章节放在书桌 B。你在书桌 B 写实验章节时书桌 A 上的主线稿纸完全不受影响。但所有稿纸都属于同一本书都是这本书的写作计划的一部分。映射回 Git 概念这本书是整个仓库的.git目录每个分支是引用refs/heads/xxx每张书桌是一个 worktree桌上的稿纸是这个 worktree 的当前工作目录。分支是逻辑概念工作树是物理目录。2.2 Worktree 的命令模型从 add 到 remove 的完整理解理解 Worktree最核心的命令就五个# 创建一个新的 worktree 并关联到新分支 git worktree add ../my-feature -b feature/new-api # 在指定的提交上创建一个 detached HEAD 的 worktree git worktree add --detach ../my-experiment commit-id # 列出所有 worktree 及其关联的分支 git worktree list # 将某个 worktree 从仓库中移除 git worktree remove ../my-feature # 清理已经没有 worktree 的陈旧分支引用 git worktree prune这里有一个特别容易误解的点git worktree add的路径参数不是分支名而是“你想把目录建在哪个路径”。很多人第一次用写的是git worktree add feature/new-api结果它会在当前目录下创建一个名为 feature/new-api 的文件夹作为 worktree而不是把分支当作目录名。这个细节初看无所谓但对目录组织有强迫症的人很关键。关联关系上每个 worktree 有且仅有一个“当前检出的分支”。默认情况下Git 禁止在同一个仓库中两个不同的 worktree 同时检出同一个分支。如果你在 worktree A 上检出 dev 分支再到 worktree B 执行git checkout devGit 会直接报错。原因很简单如果两个目录同时检出同一个分支两边文件状态不一致commit 时无法确定“哪个是权威”。2.3 分支在 Worktree 中的存活与消亡规则还有一个容易被忽略的点Worktree 会不会因为分支被删除而自动消失答案是反过来——只要某个分支还有对应的 worktree这个分支就不能被删除。你执行git branch -D删一个有 worktree 的分支时Git 会拒绝操作提示你先git worktree remove或git worktree prune。这个规则实际用起来既保护了你也偶尔造成困惑。保护你是因为只要 worktree 存在分支上的提交就不会被任何清理操作误删。困惑是因为如果你建了一堆 worktree 忘了清理仓库会越来越“重”Git 的某些操作比如 checkout 其他仓库会因为这些锁定的分支而报错。我自己习惯的清理节奏是每轮 Codex 任务完成后确认改动已 push 到远端就立即git worktree remove删除对应目录。不要囤积 worktree它和临时分支一样都是短生命周期的产物。3. Codex 场景下 Worktree 的实操落地3.1 搭建“一仓库多 Codex 并行”的目录结构下面进入实际的方案。假设我有一个项目叫my-app当前在 main 分支上现在需要让 Codex 同时做两件事一个是实现用户认证模块另一个是重构数据库查询逻辑。第一步是建立两个 worktree 目录cd my-app git worktree add ../my-app-auth -b feature/auth git worktree add ../my-app-db -b refactor/db-query执行完之后磁盘上的结构是这样的my-app/ # 原来的主工作目录仍在 main 分支 my-app-auth/ # worktree检出 feature/auth my-app-db/ # worktree检出 refactor/db-query这三个目录共享同一个.git仓库所以我在 my-app-auth 里提交代码在 my-app 里执行git log --all立刻能看到新的提交。接下来就是重头戏让两个独立的 Codex 会话分别在两个 worktree 里跑。在终端 A 进入 my-app-auth启动 Codex在终端 B 进入 my-app-db启动另一个 Codex 会话。两个 Codex 都可以读取各自的目录、修改各自的文件、运行各自的测试互不干扰。cd ../my-app-auth codexcd ../my-app-db codex这一步的精髓在于Codex 的工作目录决定了它感知到的文件系统而 Worktree 给每个 Codex 会话提供了一个完全隔离的文件系统视角。同时两个会话又共享同一个仓库的 Git 历史——当你需要合并两边成果时在任意一个 worktree 里执行git merge都行。3.2 多 worktree 环境的依赖安装与复用策略Codex 要跑测试worktree 目录里必须能安装依赖。但每个 worktree 都装一遍完整依赖既费时又费空间。这里我实测过三种方案方案一npm 硬链接。npm 本身不直接支持跨目录共享 node_modules但你可以用ln -s把主目录的 node_modules 软链接到 worktree 里。问题是如果项目在构建时执行了删除 node_modules 或者修改依赖版本的操作软链接会失效Codex 可能会因为找不到模块而报错。这个方案适合纯阅读代码或轻量改动的场景不适合重度构建。方案二pnpm 全局存储。pnpm 默认把所有包的实体存储在全局 store 里各项目的 node_modules 只是硬链接所以即使每个 worktree 都单独执行pnpm install实际磁盘占用量也远远低于 npm。这个方案对 Codex 的干扰最小因为每个 worktree 看到的都是完整的、真实的 node_modules只是物理层共享了存储。我目前最推荐这个方案。方案三在 worktree 里直接复用主目录的依赖通过调整 NODE_PATH 环境变量实现。这个方案对多数现代打包工具webpack、vite不起作用因为它们不会去 NODE_PATH 找依赖所以这里只提一句不推荐深究。依赖装完后建议在每个 worktree 里都执行一次构建命令验证环境可用。Codex 这类工具在跑测试时如果第一步就报“模块找不到”它可能会在代码里私自加依赖、乱装包反而把项目搞乱。3.3 与 Codex 自动分支行为的配合方式这里补充一个我在实践中看到的细节Codex 有自动创建分支的行为。某些版本的 Codex CLI 在启动任务时如果检测到当前分支不是 main 或 master它可能会自己新开一个分支再开始改代码或者询问你是否要创建新分支。当你把 Codex 放在一个 worktree 里时它识别到的“当前分支”就是这个 worktree 检出的分支所有自动分支的逻辑都基于这个 worktree 展开。这就产生了一个协作模式你为每个 Codex 任务显式创建一个 worktree 加分支同时告诉 Codex 在现有分支上工作不要新建分支。这样整个工作流的责任边界非常清晰worktree 是物理隔离分支是逻辑隔离Codex 在隔离环境内自由发挥。# 在 worktree 里启动 Codex 时明确要求它不要更改分支 codex --skip-git-repo-check不过要注意--skip-git-repo-check这个参数在不同版本中行为有差异。早期的 Codex CLI 会检查当前目录是否是一个干净的 Git 仓库如果发现改动未提交会拒绝执行。在 worktree 中如果上一个任务留下了未提交改动你可能需要先git stash或手动提交一次再让 Codex 接着跑。4. 常见问题与排查技巧实录4.1 Worktree 被占用导致无法删除操作中我最常遇到的报错是这样的$ git worktree remove ../my-app-auth fatal: ../my-app-auth contains modified or untracked files, use --force to delete it这个报错的本质是worktree 里还有未提交的改动。Git 担心你删掉目录后这些改动永久丢失所以拒绝删除。你可能觉得“改动我不要了”于是直接加--forcegit worktree remove --force ../my-app-auth但我建议你先冷静一下。Codex 在 worktree 里跑过的任务可能留下了很多它自己创建的新文件、临时文件、日志文件。直接 force 删掉可能把某些想要保留的探索性代码一起丢掉。更稳妥的做法是先进入 worktree执行git status看清当前状态把值得保留的改动提交到分支再回到主目录执行git worktree remove删除目录最后需要清理分支时再执行git branch -D feature/auth。如果 codex 在 worktree 里创建的大量文件都是无用产物确实不想要再用 force 也不迟。总结一句话remove 之前先看清楚有什么避免误删有价值的内容。4.2 Codex 会话“看不到”其他 worktree 的改动这是 I 在并行开发中遇到的最诡异的情况我在 my-app-db 这个 worktree 里提交了重构代码然后跑到 my-app-auth 的 Codex 会话里问它数据库层的代码是什么样的它的回答还是老版本。原因是 Codex 在对话开始时对项目做了上下文快照。如果你在会话启动后修改了其他文件Codex 并不会实时感知。它只会根据它自己所在目录的最新文件状态以及 Git 历史中的提交记录来回答问题。因为 my-app-auth 这个 worktree 和 my-app-db 共享同一个仓库理论上 Codex 可以通过查看提交历史来感知 my-app-db 的最新改动但前提是 its 当前工作的分支能访问到 refactor/db-query 分支上的提交。解决这个问题的最好办法是让两个分支之间有明确的集成点。比如我在 my-app-auth 分支上工作但希望 Codex 能看到 refactor/db-query 的改动我可以用如下命令git fetch . refactor/db-query:refs/remotes/internal/db-query这个命令把本地仓库里的 refactor/db-query 分支引用复制到一个临时远端引用 internal/db-query这样 Codex 在查看历史时就能看到它。不过更简单的做法是你直接告诉 Codex去查看某个分支的最新提交它一般会执行git show或者git log来读取相关信息。如果 Codex 还是看不到就手动切到那个 worktree 目录把关键文件的路径告诉它。4.3 在 detached HEAD 的 worktree 里意外提交git worktree add --detach创建的 worktree 不关联任何分支。这种设计适合做实验、查历史、对比提交。但这个状态下如果 Codex 在 worktree 里改了代码并执行了git commit提交会落在“悬空提交”上不会出现在任何分支引用里。一个不小心你会发现提交在仓库里存在git log --all看不到任何分支 head 都指向不到它。好在 Git 的 reflog 会记录这个提交你可以通过git reflog找回。我的经验是不要让 Codex 在 detached HEAD 的 worktree 里做有目的性的开发。detached 状态只适合临时验证。如果一定要用就严格约束 Codex 不要执行 commit等确认无误后再在主分支上通过 cherry-pick 把这些临时提交摘出来。4.4 Windows 环境下路径与符号链接的坑Windows 上使用 Worktree 有几个独有的问题我提一下第一个是路径长度限制。Windows 默认最大路径 260 字符Worktree 通常建在仓库目录的兄弟位置路径长度会叠加项目名和分支名。如果项目名本身很长再加-b feature/xxx这种长分支名某些构建工具会直接报错。解决方式是开启 Windows 的 Long Path Support或者在创建 worktree 时选择短路径比如..\auth而不是..\my-app-auth-feature。第二个是符号链接权限问题。前面提到用软链接共享 node_modules在 Windows 上创建符号链接需要开发者模式或管理员权限。如果你没有这些权限ln -s会失败。建议在 Windows 上用 pnpm 代替手动软链接方案。第三个是 Codex CLI 在 Windows 上的 Git 识别问题。有次我在 Windows 的 worktree 目录里启动 Codex它提示“无法识别当前 Git 仓库”检查下来发现是 Codex 使用了内置的 Git 检测逻辑它对 Windows 的路径分隔符处理不够好。解决方法很粗暴在系统 PATH 中确保git.exe的路径排在所有 Git 相关工具之前让 Codex 能正确调用系统 Git。5. Worktree 管理习惯与 Codex 工作流整合5.1 以任务为单位的 worktree 生命周期管理聊完了原理和坑分享一下我目前稳定使用的管理流程。这里的核心思想是把 worktree 的生命周期绑定到单个 Codex 任务的生命周期而不是当长期存在的第二个工作区。我的一天大致是这样的早上从主仓库拉取最新 main 分支准备多个任务每个任务创建一个 worktreegit worktree add ../task-auth -b task/auth-login、git worktree add ../task-db -b task/db-index在终端里分别为每个 worktree 启动独立的 Codex 会话任务完成后进入 worktree 检查 Codex 生成的代码执行测试然后 commit 并 push回到主仓库执行git worktree remove清理目录执行git branch -d删除本地分支这样做的直接好处是主仓库目录始终干干净净永远停留在 main 分支上。我不用担心 Codex 把主工作区搞乱也不用在多个任务之间来回 stash。任务的隔离性非常强视觉上也很清晰——看到my-app-task-auth这个目录就知道 Codex 正在做 auth 相关的任务。5.2 用 Git alias 简化高频操作Worktree 的命令有点长经常敲路径容易累。我用几个 alias 减少了重复输入git config --global alias.wt worktree git config --global alias.wta worktree add git config --global alias.wtr worktree remove git config --global alias.wtl worktree list配置完之后创建 worktree 就是git wta ../task-auth -b task/auth-login删除 worktree 就是git wtr ../task-auth另外我还配了一个“创建 worktree 并进入目录”的函数直接在.bashrc或.zshrc里写function wt-add() { if [ $# -ne 2 ]; then echo Usage: wt-add path branch return 1 fi git worktree add $1 -b $2 cd $1 }这个函数省去了手动 cd 的步骤对频繁建 worktree 的 Codex 重度用户来说体验提升很大。5.3 多个 Codex 会话冲突的真正风险点最后想聊一个更深层的问题多个 Codex 会话并行时它们之间会不会真的“互相打架”答案是分情况。如果每个 Codex 会话只修改自己的工作树里的文件那它们完全隔离不会冲突。真正的风险在于 Codex 可能会主动读取 Git 仓库的全局状态比如git log --all、git branch -a。当两个会话同时执行这些命令时它们看到的分支列表是相同的如果其中一个会话擅自删除了另一个会话正在使用的分支就会出问题。比如 Codex 在 task-auth worktree 里跑着我手动删除了 task-auth 分支Git 会因为该分支还有关联的 worktree 而拒绝。但如果我用git worktree remove --force強制删除 worktree 后又用git branch -D删除了分支同时另一个 Codex 会话还在那个被删的 worktree 目录里继续开发它最后 commit 时就会丢失分支引用或者报错。解决策略还是那句话不要让 Codex 在同一个仓库的多个 worktree 之间交叉跳转。一个 Codex 会话负责一个 worktree目录边界就是责任边界。如果你希望两个任务之间有信息交换通过代码提交、message 传递而不是直接文件共享。5.4 后续扩展把 Worktree 写成自动化脚手架如果你已经适应了这套工作流下一步可以做点自动化写一个简单的脚本接收“任务名”参数自动创建以任务命名的 worktree、checkout 新分支、装入依赖然后启动 Codex。比如#!/bin/bash # codex-start.sh TASK_NAME$1 WORKTREE_PATH../cs-${TASK_NAME} BRANCH_NAMEcs/${TASK_NAME} git worktree add $WORKTREE_PATH -b $BRANCH_NAME cd $WORKTREE_PATH pnpm install codex这个脚本可以大幅降低你启动一个新任务的心理门槛。原来需要敲四五个命令现在一条命令搞定。依赖安装也放在脚本里避免 Codex 在后续执行中因为缺少模块而中断。6. 写在最后的经验与建议Worktree 这个东西实际上就是给 Git 分支的“多方向同时工作”提供物理层面的支持。没有它分支只能串行切换有了它分支才能真正并行推进。尤其是面对 Codex 这种 AI 编程工具它会频繁改动文件、可能中途出错、需要反复调整任务指令。没有隔离的工作环境AI 产生的混乱会直接蔓延到你的主工作区。我个人在实战中最大的体会是不要把 Worktree 当成一个“高级技巧”收藏起来它其实是每个 Codex 用户都该尽早纳入日常工作流的基础设施。它没有太多复杂概念核心就是 add、list、remove 三个命令。但就是这个简单的操作能让你的 AI 编程体验从“提心吊胆”变成“各司其职”。最后再分享一个小技巧如果你频繁使用 Codex 处理不同的任务建议把任务名作为分支名和 worktree 路径的统一前缀。比如所有 AI 相关的任务都用ai/开头这样一眼就能通过目录看清当前哪些工作是 AI 生成的哪些是你手动写的管理起来会清爽很多。
