开发工具

前言 你是否经历过这样的场景？ 当你正在为某个功能跑漫长的测试时，突然来了一个紧急的 bug 要修复，但你又不能随便动工作区的代码，因为测试还在进行。此时只能无奈地切换分支，导致 node_modules 需要重新安装，编译需要重新进行… Git Worktree 就是来解决这个问题的。它允许你在同一个 Git 仓库中同时维护多个工作目录，每个目录可以检出不同的分支，彼此独立。 这篇文章将从理论到实战，深入讲解如何使用 Git Worktree 来优化你的开发流程。 什么是 Git Worktree？ 基本概念 Git Worktree（工作树）是一个 Git 特性，允许你在同一个 Git 仓库中创建多个工作目录。 在没有 Worktree 之前： 一个仓库 = 一个工作目录 切换分支会改变当前工作目录的文件状态 如果当前工作目录有未提交的改动，切换分支可能很困难 有了 Worktree 之后： 一个仓库 = 多个独立的工作目录 每个工作目录可以检出不同的分支 多个目录可以同时进行开发，互不影响 工作树 vs 传统分支 常见误解： 工作树是对分支的替代 正确理解： 工作树是对分支的一种**“文件系统视图”** 分支：Git 中用来隔离开发路线的概念，存储在 .git/refs/heads/ 中 工作树：只是物理上创建了一个新的目录，让你能同时看到/编辑多个分支 分支的数量和数目都不会因为创建工作树而改变，工作树只是给了你一个新的"窗口"去访问这些分支。 为什么需要 Git Worktree？ 常见应用场景 1️⃣ 场景：修复紧急 bug，不中断当前工作 你正在 feature/new-api 分支上开发新功能，代码还未提交。突然生产环境爆出一个 bug，需要立即修复。 传统做法： # 代码还没 commit，必须先 stash git stash # 切回 main 分支 git checkout main # 修复 bug，提交 git commit -m "fix: xxx" # 切回开发分支 git checkout feature/new-api # 恢复代码 git stash pop 问题：如果项目很大（如前端项目有巨大的 node_modules），即使只是切换分支也要重新安装依赖！ ...