Git通过物理分支隔离基础框架代码与具体业务逻辑方案-git-PHP中文网

git worktree add 比 git checkout 更适合隔离基础框架和业务逻辑，因其创建物理独立目录、分支绑定且不共享工作区状态，避免未提交修改跨分支污染。

git通过物理分支隔离基础框架代码与具体业务逻辑方案

git worktree add 为什么比 git checkout 更适合隔离基础框架和业务逻辑

直接用 git checkout 切换分支，会把未提交的修改带过去或强制阻断——这对“基础框架代码”这种长期稳定、极少改动但又需随时验证的场景极其危险。而 git worktree add 创建的是物理上完全独立的目录，每个目录绑定一个分支，彼此不共享工作区状态，天然避免污染。

常见错误现象：git checkout feature/payment 后发现 src/main/java/com/example/framework/ 里多出几行调试日志，其实是之前在 dev 分支改的还没提交，被带过来了。

框架代码建议固定在 main 或 stable/framework 分支，用单独工作树打开，只读+验证
每个业务模块（如 feature/report、hotfix/login）都用独立工作树，路径建议按语义命名：./worktrees/report-dev、./worktrees/login-fix
不要把工作树建在 IDE 默认项目目录下（比如 VS Code 打开的根目录），否则可能触发重复扫描或缓存冲突

如何让不同工作树共享同一套构建配置但隔离源码路径

Spring Boot 项目常因 pom.xml 中的 sourceDirectory 或 IDE 的 module 设置默认指向项目根目录，导致多个工作树编译时互相干扰。关键不是改构建逻辑，而是控制路径解析源头。

使用场景：你在 ./worktrees/auth-dev 里改登录逻辑，同时在 ./worktrees/framework-stable 里验证框架升级包是否兼容——两者必须能各自 clean compile，互不影响。

Cnb Cool Git

CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。

下载

确保 pom.xml 中不硬编码绝对路径，所有 <sourcedirectory></sourcedirectory> 都用相对路径（如 src/main/java）
VS Code 打开工作树时，务必用 code ./worktrees/auth-dev 而非 code .，否则 Java 插件会从根目录加载 classpath
如果用 Maven wrapper，每个工作树应独立执行 ./mvnw clean compile，不要共用 target/ 目录（它默认在各自工作树内）

git worktree prune 容易误删正在用的工作树

git worktree prune 本意是清理已删除目录对应的工作树条目，但它不会检查该工作树是否正被 IDE 或终端占用。一旦误执行，VS Code 可能还在编辑其中文件，Git 却已从内部记录中抹掉该条目，后续 git status 在那个目录会报错：fatal: this operation must be run in a work tree。

参数差异：git worktree prune -n 是安全预览模式，只打印将被删的条目，不真删；而默认无参数就是强制执行。

日常清理前必加 -n，确认输出里没有你正在用的路径
工作树目录名别用纯数字或带空格（如 1.2.0、hot fix），Windows 下容易被 prune 错判为无效路径
VS Code 关闭对应窗口后再运行 prune，避免编辑器后台进程锁住目录

IDE 缓存与工作树切换的隐性冲突

IntelliJ 和 VS Code 都会在首次打开项目时生成索引和缓存（如 .idea/、.vscode/），这些文件默认放在工作树根目录。当你用 git worktree add 新建工作树后，IDE 若沿用旧缓存，会把两个工作树的类路径混在一起，导致跳转到错误分支的源码。

性能影响：缓存错位会导致 “Go to Definition” 指向 feature/a 的实现，而当前实际在 feature/b 工作树里编码。

VS Code 推荐在每个工作树根目录下放独立的 .vscode/settings.json，禁用全局缓存："files.exclude": {"**/.git": true} 不够，要加 "java.configuration.updateBuildConfiguration": "interactive"
IntelliJ 用户必须关闭 “Store relative paths in project files”，并在每个工作树里重新 Import Project，而不是 Open
最稳妥做法：所有工作树统一用命令行构建（./mvnw），IDE 仅作编辑器，不托管构建生命周期

真正麻烦的不是创建多个工作树，而是它们共享同一个 .git 目录却各自维护独立的 index 和 HEAD。框架代码更新后，你得手动 git pull origin main 进入框架工作树，再 git merge 或 git rebase 到各业务分支——这个同步动作没人帮你自动做，也很难用脚本兜底。