我见过一个开发者的电脑，Git仓库克隆了7份，命名从project-v1排到project-v7。问他为什么，他说"这样切换分支干净"。

这像什么呢？就像有人为了区分工作日和周末的衣服，买了两套一模一样的衣柜。

Git worktree 的存在感极低，低到什么程度？官方文档把它塞在角落里，Stack Overflow 上关于它的讨论量只有分支管理的零头。但这个小功能解决的正是"多版本并行"的痛点——不用克隆多份仓库，一个目录里就能同时检出多个分支，各自独立运行。

不过话说回来，worktree 的学习成本是真实存在的。路径管理、裸仓库配置、IDE 识别问题，随便踩一个坑都能浪费半小时。相比之下，"克隆多份轮着用"的方案堪称朴素智慧：固定目录、pull 最新、checkout 新分支、提 PR 合并。没有认知负担，出了问题直接删了重 clone，容错率极高。

工具选型里有个隐形规律：能靠"笨办法"稳定运行的，往往比"优雅方案"活得更久。我见过太多团队引入复杂工作流，最后因为某人离职、文档缺失，变成没人敢动的遗产代码。

当然，如果你经常要在两个分支间来回 diff，或者需要同时跑多个版本的本地服务，worktree 确实能省掉不少git stash的焦虑。但它不是必修课，只是选修。

有个细节挺有意思：Git 官方仓库本身就在用 worktree 管理——他们的持续集成系统会同时检出多个分支并行测试。但普通开发者没这个需求，硬上就是过度设计。

最后说个用户反馈。某次内部分享会后，一个后端工程师私信我："听了 worktree 的用法，回去试了一小时，第二天默默改回了多目录方案。不是功能不好，是我的脑子不好。"