Git利用分支实现项目前后台代码在同一仓库的物理隔离-git-PHP中文网

git分支无法实现物理隔离，因其本质是轻量指针，所有分支共享同一工作目录和.git对象库，切换分支不清理文件；真正物理隔离需依赖单仓库双目录、git worktree或多仓库子模块等方案。

git利用分支实现项目前后台代码在同一仓库的物理隔离

为什么不能直接用 Git 分支做前后台物理隔离

Git 分支本质是轻量指针，所有分支共享同一份工作目录和 .git/ 对象库。切换 git checkout backend 或 git switch frontend 不会自动清空或隐藏另一端的文件——你删掉的 src/main/java 还在磁盘上，src/pages 也照常存在。所谓“隔离”，只是提交历史分离，不是文件系统层面的隔离。

真正能实现物理隔离的三个可行方案

要让前端代码不进后端构建流程、后端配置不被前端 CI 误读，必须靠文件路径或工具层控制，而非仅靠分支。常见有效做法如下：

单仓库双目录结构：根目录下明确划分 frontend/ 和 backend/，CI 配置（如 GitHub Actions 的 paths:）按目录过滤触发；各端只 npm install 或 mvn compile 自己目录下的内容
Git 工作树（worktree）配合分支：用 git worktree add ../myapp-frontend frontend 和 git worktree add ../myapp-backend backend 创建两个独立文件夹，分别绑定不同分支。此时两个目录互不干扰，IDE 可分别打开，但需手动同步 .gitignore 和共享配置（如 package.json 中的 lint 规则）
子模块（submodule）或 subtree（慎用）：把前端作为 frontend/ 子模块引入主仓库。虽能物理隔离，但日常开发中 git submodule update --init 易出错，且 IDE 对跨 submodule 调试支持弱；git subtree 合并逻辑复杂，历史追溯困难，非必要不推荐

分支命名与 CI 配置的关键细节

即使采用双目录结构，分支策略仍影响交付可靠性：

Git

程序猿必备版本控制工具

下载

避免用 main 直接承载全栈代码——它应只接受已验证的、前后端都通过的合并。推荐设 main 为发布线，dev-frontend / dev-backend 为各自开发线，通过 PR 合并前强制运行对应目录的 npm test 或 ./gradlew test
GitHub Actions 中，on.push.paths 必须精确匹配目录，例如：
```
on:
  push:
    paths:
      - 'frontend/**'
      - '.github/workflows/frontend.yml'
```
否则 backend/src 修改可能意外触发前端构建
.gitignore 要分层写：根目录忽略通用构建产物（node_modules/, target/），但 frontend/.gitignore 可额外忽略 dist/，backend/.gitignore 忽略 logs/，避免误删

最容易被忽略的坑：环境变量与密钥泄漏

前后端共仓时，.env 文件极易混放。比如 backend/.env 里有 DB_PASSWORD，若不小心被前端构建脚本读取并打包进静态资源，就彻底暴露。

绝对不要在 frontend/ 下放任何含敏感信息的 .env；前端所需配置走构建时注入（如 Vite 的 import.meta.env.VUE_APP_API_BASE），且值必须来自 CI secrets
backend/src/main/resources/application.yml 若含 profile-specific 配置，需确认 git ls-files 不会把它当作前端资产一并上传到 CDN
本地开发时，用 export NODE_ENV=development + cross-env 控制行为，别依赖分支名判断环境——git checkout dev-frontend 不等于“前端开发模式”