Git Worktree 让多个 AI 代码助手并行工作，而不冲突
在同一个代码库里同时启动多个 AI 代码助手时，如果它们都指向同一个工作目录和分支，文件读写冲突几乎不可避免。以 OpenCode 为例，它是一个开源工具（GitHub 星数 208K、贡献者 950 名），支持在终端、IDE 或桌面环境中协助编码，且采用隐私优先设计，不会存储用户的代码或上下文。但即使如此，如果两个终端同时修改同一个文件，依然会导致合并失败或代码丢失。
解决方案不需要更换工具，而是利用 git worktree 创建物理隔离的工作区。该功能允许在同一 Git 仓库下维护多个工作目录，每个目录可独立检出不同分支，但共享同一套 .git 数据库。这意味着所有提交、分支和对象都保持同步，而文件修改互不干扰。
如何配置独立工作区？
假设当前在 project/main 目录，需要让两个 AI 代码助手分别处理登录和支付功能。通过以下命令创建独立工作区：
# 集成测试目录，基于 integration 分支（从 main 分支创建）
git worktree add ../integration -b integration main
# 登录功能专用目录，基于 feature/login 分支
git worktree add ../feature-login -b feature/login main
# 支付功能专用目录，基于 feature/payments 分支
git worktree add ../feature-payments -b feature/payments main完成后，目录结构如下：
project/
├── main/ # 主分支工作区
├── integration/ # 集成测试区（用于合并验证）
├── feature-login/ # AI 代码助手 1 专用区
└── feature-payments/ # AI 代码助手 2 专用区每个 AI 代码助手在各自的终端中运行时，由于物理路径完全隔离，无需担心文件锁定或修改冲突。例如，在 feature-login 目录启动 OpenCode（通过 curl -fsSL https://ai/v2/install | bash 安装），在 feature-payments 目录启动另一个助手，两者独立工作。
无需推送即可合并
由于所有工作区属于同一本地仓库，合并流程无需远程推送或拉取。假设 AI 代码助手在 feature-login 完成登录逻辑后提交：
cd feature-login
git add .
git commit -m "feat: implement login"直接切换到集成目录合并：
cd ../integration
git merge feature/login
git merge feature/payments
npm test这种方式避免了远程仓库的网络延迟和权限限制，特别适合团队协作时的快速迭代。只要各个工作区的分支基于同一主线（如 main），合并时冲突概率极低。
全部回复 （3）
想当场把话说完？进全球 AI 聊天室，登录就能开口。
千万别直接在主分支跑，我上次被它改乱了三个文件，心态直接崩了，特别是同时跑多个 Coding Agent 时，很容易踩坑，就像我之前在同一个仓库里开过两个终端，一个让 Claude Code 处理登录逻辑，另一个让 Codex 搞支付功能，结果俩 Agent 在同一个工作目录、同一个分支下操作，改同一个文件，代码冲突和文件读写冲突直接把工作流炸了，而且解这个问题不用换更强的模型，而是把 Git 里那个很多人没太用过的功能用起来：git worktree，它的思路挺巧妙：同一个仓库底下，你能拿到多个互相独立的物理工作目录，每个目录可以检出不同的分支，但它们共用同一套 .git 数据库，所有 commits、branches、objects 都是共享的，比如直接在主目录外面开新的 worktree：# 创建登录功能的独立工作区 git worktree add ../feature-login -b feature/login main，现在给每个 Agent 分配一个独立的终端窗口，各干各的，物理路径完全隔离，Agent 之间根本没机会互相踩脚。
快告诉我你是怎么分分支跑的，我现在的代码库已经被它搅成浆糊了。 我之前就在同一个仓库里开过两个终端，一个让 Claude Code 处理登录逻辑，另一个让 Codex 搞支付功能。结果俩 Agent 在同一个工作目录、同一个分支下操作，改同一个文件，代码冲突和文件读写冲突直接把工作流炸了。 其实解这个问题不用换更强的模型，而是把 Git 里那个很多人没太用过的功能用起来：git worktree。 它的思路挺巧妙：同一个仓库底下，你能拿到多个互相独立的物理工作目录。每个目录可以检出不同的分支，但它们共用同一套 .git 数据库，所有 commits、branches、objects 都是共享的。 实操配置流程是这样的：假设你现在在 project/main 目录下，想让两个 Agent 分别去搞登录和支付，直接在主目录外面开新的 worktree：
# 创建一个用于集成测试的目录，分支叫 integration git worktree add ../integration -b integration main # 创建登录功能的独立工作区 git worktree add ../feature-login -b feature/login main # 创建支付功能的独立工作区 git worktree add ../feature-payments -b feature/payments main跑完之后，你的目录结构长这样：
project/ ├── main/ # 当前在 main 分支 ├── integration/ # 在 integration 分支，用来跑集成测试 ├── feature-login/ # Agent 1 的专属领地 └── feature-payments/ # Agent 2 的专属领地现在给每个 Agent 分配一个独立的终端窗口，各干各的：
cd feature-login # 启动 Agent 1 cd feature-payments # 启动 Agent 2物理路径完全隔离，Agent 之间根本没机会互相踩脚。
三个 worktree 同时开，node_modules 差点把我的 SSD 给撑爆了。我之前就在同一个仓库里开过两个终端，一个让 Claude Code 处理登录逻辑，另一个让 Codex 搞支付功能。结果俩 Agent 在同一个工作目录、同一个分支下操作，改同一个文件，代码冲突和文件读写冲突直接把工作流炸了。其实解这个问题不用换更强的模型，而是把 Git 里那个很多人没太用过的功能用起来：
git worktree。它的思路挺巧妙：同一个仓库底下，你能拿到多个互相独立的物理工作目录。每个目录可以检出不同的分支，但它们共用同一套.git数据库，所有 commits、branches、objects 都是共享的。假设你现在在project/main目录下，想让两个 Agent 分别去搞登录和支付，直接在主目录外面开新的 worktree：跑完之后，你的目录结构长这样：
现在给每个 Agent 分配一个独立的终端窗口，各干各的：
物理路径完全隔离，Agent 之间根本没机会互相踩脚。这玩法最爽的一点是，完全不用走
git push和git pull那套老流程。因为所有 worktree 都属于同一个本地仓库，Git 内部是通的。Agent 1 在feature-login目录下把活干完 commit 之后：不用推送到远程，直接切到集成目录合并就行： ```bash cd ../integration git merge feature/login git merge feature/payments npm test