Git worktree 实战：保留当前现场，同时开一个修复目录
功能做到一半，线上问题突然需要修复。与其反复保存现场、切换分支和恢复依赖，可以为同一个仓库增加一个工作目录。Git worktree 适合并行查看不同分支、验证历史提交或临时修复；它共享仓库数据，但每个目录拥有自己的检出状态。本文所有路径都应先替换成你的测试仓库路径。
AI生成概念配图：一个仓库连接两个互相独立的开发工作目录，仅辅助理解，不代表真实界面或实测结果。
先确认修复要从哪里开始
git status --short git worktree list git fetch origin git worktree add -b fix/login-timeout ../project-hotfix origin/main git -C ../project-hotfix status --short --branch
示例假设 origin/main 是团队确认的修复起点。如果生产运行在维护分支或标签，就应该从对应提交开始。fetch 只更新远端跟踪信息，不会把当前目录中未提交的改动带进新目录。新目录也不会自动包含被忽略的配置文件、依赖目录或本地数据库，必须单独准备运行条件。
在原目录的改动会留在原处，不需要为了创建 worktree 先做一笔没有意义的提交。与此同时，新目录是一个新的现场：打开编辑器后先核对路径和分支，终端提示符最好展示分支名。相同项目的窗口长得很像，误在旧窗口提交往往比命令本身更值得防范。
让两个工作目录真正可以并行
代码目录隔离，不等于运行资源隔离。两个开发服务器可能争抢同一个端口，也可能连接同一个测试数据库。建议为临时修复指定单独端口、独立缓存目录和明确的测试数据集。复制本地配置之前先检查密钥和外部服务地址，避免在回放旧版本时向真实用户发送通知。
Git 默认会阻止同一分支同时在多个工作树中检出。这是保护机制：共享分支引用若在一个目录中被推进，另一处索引和文件可能让人误判当前状态。遇到“分支已检出”的错误，先看 worktree list；通常应选择新分支或只读查看方式，而不是立刻加 --force 绕过检查。
临时审查可以使用 detached HEAD
git worktree add --detach ../project-review origin/main git -C ../project-review log -1 --oneline git -C ../project-review status --short
detached HEAD 适合检出一个确定提交做测试。如果随后决定保留修改，应在提交前创建命名分支，或及时为已有提交建立分支引用；不要把临时目录当成长久保存成果的位置。团队协作仍应通过清晰的提交、推送和评审流程，worktree 本身不会自动合并两边的修改。
结束时先检查，再移除
git -C ../project-hotfix status --short --ignored git worktree remove ../project-hotfix git worktree list
移除前先检查未提交修改、未跟踪文件和被忽略的本地产物，并另行保存需要保留的内容。尤其不要把 Git 的“干净”判断等同于忽略文件也会得到保护。remove 默认拒绝移除不干净的工作树；若命令失败，应先找出原因，不要直接改用强制删除。移除工作树不会自动删掉修复分支；分支是否删除应等合并和远端保存确认后再决定。普通目录删除还可能留下管理记录，因此优先使用 worktree 子命令。
对于暂时离线的移动磁盘工作树，可以考虑 worktree lock 防止其管理记录被清理。若只是想释放已经明确废弃的记录，则先看 prune 的预览结果。我的判断标准是：需要并行现场时用 worktree，需要完全独立配置、权限或仓库生命周期时，再考虑单独克隆；两者解决的问题并不相同。
