git worktree 对 winwsl2 协作的妙用

问题描述：

和 claude 配合的痛点

身为 windows 用户 + c# 开发(重度依赖 rider)，没办法像 macos/linux 用户那样，无感使用 claude/codex 配合开发，因为如果在 powershell 中启动，就总是会因为命令/编码问题，白白试错，感觉观感上很差。
同时 rider 在 wsl 上的体验又很差，也没法像 前端/python/go/rust 等用户那样，直接用 vscode remote 就能正常使用。
导致一直以来，我都是用这样的方式开发：仓库放在 win 路径下，ide 直接打开，然后在 wsl 中启动 claude/codex 进行开发。这样的配置拿来做开发，大部分场景都能很好的配合。

但是在我引入工作流的时候，agent 会在完成任务后，自行调用 dotnet test 命令去测试完成的内容，测试是否达到 spec 的目标。这时候就出现问题，由于 dotnet test 命令，会导致使用 wsl 下的 sdk 进行编译，这时候我在 win(ide) 下的编译产物就被顶替掉，然后界面爆红。实际上只要我在 ide 中再点一下编译就行了，这样的操作让我觉得难受，但也没办法。

---

解决方案

今天早上突然想到，刚认识了 git worktree 命令(claude 每次都问我要不要新开一个 worktree 隔离工作区)，那我能不能用来解决这个协作问题，今天早上花了一上午和 ai 沟通，找到了一个工作模式。

直接放结果

~/git-store/project.git (bare) ├── worktree → E:\workspace\project-dev [dev] IDE, 程序员 └── worktree → ~/workspace/project-agent [agent] Claude Code, Codex ├── worktree → ~/workspace/project-agent-feat-xxx (临时) └── worktree → ~/workspace/project-agent-fix-yyy (临时)

整体思路就如上所示：

1. 我们通过 worktree 在 win 下创建一个分支目录，我们就在这上面进行开发 review。
2. 然后在 wsl 下，再创建一个 worktree 目录，并在这个目录下启动 claude/codex 等工具，和AI交互沟通，让它在这个目录/分支下进行编码开发。（如果有需要，可以继续 worktree 新的分支）
3. ai 完成一个对话/阶段任务后，变更的代码直接 commit，此时我们在 ide 中可以选择 pick 或者 merge 这次提交，然后在 ide 中审查。此时我们有几个不同的场景：
4. 结果不满意，或者未完成，想要让 ai 继续开发 → 那么我们就继续聊，让 ai 继续开发，然后commit，然后我们回到第 3 步。
5. 结果不满意，甚至觉得反向错了，想要回退 → dev(win) 丢弃变更，重置工作区，同时 agent(wsl) 用 reset dev 的方式重置(可以让 ai 代劳)
6. 结果很满意，完成了阶段性任务 → dev(win) 整理内容，将变更内容合并为一个 commit，然后就可以 push 了。agent(wsl) 就直接用 reset dev 的方式，重置工作区。

---

有何利弊

整个流程上看，考虑到不同场景，逻辑也是闭环的。

在我看来，帮我解决了一些问题：

1. 原先的在 wsl 下，访问 /mnt 路径，跨文件系统时的性能问题
2. 原本的方式，会导致编译产物的替换 (c# 里 obj/bin 文件夹)，导致 ide 不认了（甚至 vscode 也会这样）。现在没这个问题
3. 引入了一个中间层的 workspace (agent 分支)，这样 ai 的中间动作，可以随意的 commit，然后继续下一步。（其实很牵强 ，原先也能随意 commit，只要最后压缩一下就行，毕竟 git 就是干这个的）
4. claude/codex 在 wsl2 下运行，不会有 powershell 下奇奇怪怪的问题
5. 对 claude/codex 无感，也不会影响到原先 claude 对 worktree 的支持
6. 用到了刚学的 worktree，哪怕没必要

这样的方法实际上也会有些问题：

1. 最大的问题，那就是 agent 每次的改动，都必须 commit 后，我再手动 pick，才能看到，这是个问题。某种意义上，也算是隔离了。我暂时想到的是在 claude.md 中声明这个动作。
2. 多倍的编译产物/依赖，占据空间。比如 node_modules，不过我用的 pnpm，可以解决很多问题
3. win/wsl2 下双端同时都在编译，就需要两边都有 sdk。不过原先就是这样，放两个 sdk 也没问题
4. 整个工作流程复杂度是有提高的。这个没得说，为了解决协作的问题，确确实实需要多余的步骤。

---

Q: 为什么需要一个 wsl 下的 worktree (agent 分支)？用老方案的，继续在 /mnt/e 路径下启动 ai，然后让他变更时用 worktree 就行了，只是读取文件性能稍慢，但并不影响 ai 开发。
A: 只能说这个方案带来的好处并没有那么大，但我就是要用

Q: AI 的每次变更，都必须 commit，然后我再手动 pick 到当前分支，有种脱裤子放屁的感觉。有时候有些更改就一句话的事情，有够麻烦的
A: 这就是这个方案的最大问题，只能说暂时就这么搞。写在 claude.md 或者 hook 中，让 AI 在每次对话结束后/阶段完成后，去立马 commit。

---

操作步骤

对于整个流程的操作命令如下

# bare 仓库可以推荐放在 wsl 下 mkdir -p ~/git-store cd ~/git-store git clone --bare https://github.com/user/project.git # 两种方法，更推荐第二个 # 方法一: 在 powershell 中创建 # 在 wsl 下运行 git worktree 时，会发现你创建的这个 worktree 的路径是 win 风格 # 使用 lock 参数，避免调用 git worktree prune 时误删 # 删除时也需要在 powershell 中删除 git --git-dir=\\wsl.localhost\<你的发行版>\home\<用户名>\git-store\project.git ` worktree add -b dev ` --lock --reason "humen dev" ` E:\workspace\project-dev dev # 方法二: 在 wsl 中创建 # 创建后，直接用 ide 打开会无法识别 git 信息，需要修改文件 git worktree add -b dev ' --lock --reason "humen dev" ' /mnt/e/workspace/project-dev dev # 此时打开 win 目录下的 E:/workspace/project-dev/.git 文件，修改内容 # 原内容: gitdir: /home/user/git-store/project.git/worktrees/project-dev # 修改成 win 风格 getdir: \\wsl.localhost\<你的发行版>\home\<用户名>\git-store\project.git\worktrees\project-dev # 第三步，创建 agent worktree mkdir -p ~/workspace git worktree add -b dev ' --lock --reason "ai agent base" ' ~/workspace/project-dev dev 网友解答：

---

--【壹】--：

这个方法其实对于Codex 或者 Codex App也很有参考价值。谢谢。