VS Code Git 工作树：告别频繁切分支，实现多分支并行开发实战方案

前言：

[一、什么是 Git Worktree？](#一、什么是 Git Worktree？)

[二、两种创建工作树方式：命令行 + VS Code 可视化](#二、两种创建工作树方式：命令行 + VS Code 可视化)

[方式 1：命令行](#方式 1：命令行)

[方式 2：VS Code 原生可视化操作](#方式 2：VS Code 原生可视化操作)

[三、嵌入式项目推荐 worktree 目录规范](#三、嵌入式项目推荐 worktree 目录规范)

前言：

相信不少开发者都遇到过这样的场景：正在feature/uart-optimize分支开发串口优化功能，代码写到一半，测试反馈主线main分支存在紧急 Bug 需要修复。

传统 Git 开发流程只能二选一：

git stash暂存当前半成品代码，切换分支修复 Bug，完成后切回来恢复；
复制整个项目仓库，两份目录分别对应不同分支，但是占用大量磁盘空间，同步更新麻烦。

第一种方式容易忘记 stash、冲突频发；第二种会产生两份独立.git仓库，维护成本很高。而 Git worktree（工作树） 就是专门解决该痛点的方案，新版 VS Code 已经原生内置可视化支持，无需安装第三方插件。同一个远端仓库只保存一份 Git 数据库，同时创建多个独立工作目录，每个目录绑定不同分支，互不干扰，真正做到多分支并行开发。

一、什么是 Git Worktree？

Git 2.5 版本引入 worktree 功能，核心逻辑：

一个主仓库 （包含完整.git数据库，保存所有提交记录、分支、标签）

多个附属工作树目录，仅存放源码文件，不复制完整 git 数据库，节省磁盘空间

每个工作目录固定绑定一个分支，同一分支不能同时在多个工作树检出

通俗来说：一份代码仓库本体，"分出多个文件夹分身"，每个文件夹可以跑不同分支。修改、编译、调试完全隔离，分支之间切换不再需要覆盖本地文件。

典型适用场景：

新功能开发中，并行处理线上紧急 hotfix；

需要同时对比两个分支代码实现差异；

多版本并行调试，一边维护稳定版本，一边迭代新特性；

嵌入式项目：main稳定版本、feature新功能分支、hotfix修复分支同时编译测试。

二、两种创建工作树方式：命令行 + VS Code 可视化

方式 1：命令行

进入主仓库根目录 执行命令

复制代码

# 基础语法：git worktree add [目标目录路径] [分支名]
# 创建hotfix工作树，目录放在主仓库同级
git worktree add ../worktree-hotfix hotfix/v1.3-bugfix

# 创建新分支并同时生成工作树（-b）
git worktree add ../worktree-new-feature -b feature/spi-driver

常用管理命令

复制代码

# 查看当前所有工作树列表
git worktree list

# 删除不再使用的工作树（推荐命令删除，不要手动删文件夹）
git worktree remove ../worktree-hotfix

方式 2：VS Code 原生可视化操作

打开主仓库项目，进入「源代码管理」面板；

在仓库一栏点击右上角...更多操作；

选择 Worktrees > Create Worktree；

弹窗选择目标分支，设置新工作目录保存路径，确认自动创建；

创建完成后，可以直接在 VS Code 新窗口打开该目录，独立编辑、运行、调试。

💡 最佳实践：每个工作树目录使用独立 VS Code 窗口打开，终端、编译环境、调试配置完全隔离，避免混淆。

三、嵌入式项目推荐 worktree 目录规范

我在项目中长期使用这套目录结构，方便管理：

复制代码

project-root/          # 主仓库（main分支）
├── worktree-feature/ # worktree：新功能分支
└── worktree-hotfix/  # worktree：紧急修复分支

规则：所有附属工作树统一放在主仓库同级目录，命名规范 worktree-分支名称，一眼区分用途。

四、完整开发工作流示例

当前在project-root（主仓库，feature 分支开发驱动）

收到线上 Bug，执行命令创建 hotfix 工作树 git worktree add ../worktree-hotfix main -b hotfix/uart-fix

VS Code 单独打开worktree-hotfix目录，基于主线修复问题、编译、测试

修复完成，提交代码、推送远端，合并到 main 分支

不再需要时执行：git worktree remove ../worktree-hotfix清理目录

切回原 feature 窗口，继续新功能开发，全程不需要暂存、覆盖本地代码。

五、重点避坑清单

禁止手动删除 worktree 文件夹！手动删除目录后，Git 内部依然保留该工作树记录，后续创建同名工作树会报错。必须使用 git worktree remove 正常卸载。

同一个分支不能同时绑定多个工作树 Git 不允许一个分支在多个目录同时检出，防止文件冲突。如果需要并行测试同一分支不同配置，只能复制完整仓库。

附属工作树没有独立.git 文件夹打开 worktree 目录你只会看到.git文件（是一个指向主仓库的链接），不是文件夹，不要误删。

谨慎在 worktree 之间直接拷贝文件分支之间代码同步优先使用cherry-pick、merge等 Git 标准操作，手动复制容易丢失提交记录。

嵌入式注意编译产物隔离每个工作目录独立编译，建议将.o、可执行文件、build 产物加入.gitignore，避免跨目录干扰。

六、对比三种多分支方案优劣

方案	优点	缺点	适用场景
git stash + 切换分支	无需额外目录，零空间占用	半成品代码容易遗忘、频繁暂存冲突多	临时简单修改
完整复制仓库	完全隔离，自由度最高	占用双倍磁盘，同步麻烦	长期维护互不相关大版本
Git worktree	共享 git 数据库、节省空间，分支隔离	仅支持不同分支并行	绝大多数日常开发（推荐首选）

七、个人配置总结

结合嵌入式 C 工程开发，我的标准化配置方案：

优先使用 VS Code 可视化创建工作树，减少记忆命令成本；

所有临时 hotfix、长期 feature 全部通过 worktree 创建独立目录；

不同工作树独立 VS Code 窗口打开，区分终端；

项目.gitignore统一屏蔽编译中间文件；

任务完成后及时执行git worktree remove清理废弃目录，避免堆积；

紧急修复优先基于 main 分支新建 hotfix 工作树，不污染正在开发的 feature 代码。

结语

很多开发者长期依赖stash切换分支，饱受上下文混乱的困扰。Git worktree 并不是冷门黑科技，而是提升多任务并行效率的实用工具，搭配新版 VS Code 原生支持后，上手门槛大幅降低。

尤其是嵌入式开发者，工程编译耗时久、环境配置复杂，频繁切换分支重新编译会浪费大量时间。借助工作树，多个分支可以同时保持编译环境，随时切换调试，极大提升开发流畅度。

如果你还在反复暂存代码来回切分支，不妨尝试这套 worktree 工作流。

互动讨论

你平时开发中如何处理多分支并行开发？有没有遇到 Git 切换分支带来的各种麻烦？欢迎评论区交流 worktree 使用踩坑经验！