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 沟通,找到了一个工作模式。
和 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 沟通,找到了一个工作模式。

