Git分支与服务器的映射由CI/CD工具通过CI_COMMIT_BRANCH变量条件判断实现，需显式配置“分支→目标地址”规则：main/master部署至生产服务器（如192.168.1.30），需人工审批；develop部署至测试服务器（如192.168.1.20），自动触发但禁外网；feature/*仅部署至开发服务器（如192.168.1.10）并配临时域名；所有IP和配置须通过环境变量或secret注入，禁止硬编码；部署采用git clone -b而非git checkout，确保工作树干净、无历史残留，推荐--depth 1加速；各环境须物理隔离路径、端口及日志目录，Spring Boot profile须由脚本动态注入。
production / develop / feature 分支怎么对应到不同服务器？
映射不是 Git 自身的功能，而是靠 CI/CD 工具（比如 GitLab Runner）在流水线中根据 CI_COMMIT_BRANCH 变量做条件判断来实现的。你不能只靠分支名就自动部署到某台机器，必须显式写清楚“哪个分支 → 哪个目标地址”。
-
master或main分支的 job 应该只允许部署到生产服务器（如192.168.1.30），且需人工审批或二次确认 -
develop分支的 job 部署到测试服务器（如192.168.1.20），可设为自动触发但禁止访问外网 -
feature/*分支默认不部署，或仅部署到开发服务器（如192.168.1.10）且带临时域名（feat-xxx.dev.example.com）
注意：不要在脚本里硬编码 IP，应通过 runner 的 variables 或环境级 secret 注入，避免配置泄露。
为什么用 git clone -b 拉取特定分支而不是 git checkout？
因为部署目标机上通常没有完整仓库历史，也不需要保留 .git 目录。直接 git clone -b production git@repo:app.git /opt/app/prod 能确保工作树干净、无残留暂存/未提交内容，且避免 git checkout 在已有目录下可能引发的冲突或覆盖风险。
- 每次部署都应是“全新克隆 + 构建”，而非在旧工作树上
git pull—— 后者容易因本地修改导致状态不可控 - 如果用
git checkout，必须先git clean -fdx和git reset --hard，但不如 clone 简单可靠 -
git clone --depth 1可加快拉取速度，适合纯部署场景（无需历史记录）
如何防止不同环境分支部署时互相污染？
关键在于物理隔离：每个环境使用独立目录、独立端口、独立配置文件路径。哪怕都在同一台机器上，也不能共用 /opt/app 这样的通用路径。
- 生产环境路径建议为
/opt/app/production，测试为/opt/app/testing，开发为/opt/app/development - Spring Boot 的
spring.profiles.active必须由部署脚本注入，不能靠 jar 包内默认值；例如：java -Dspring.profiles.active=prod -jar app.jar - 配置文件（如
application-prod.yml）不应放在代码库中，而应通过外部挂载或 runner variables 注入
最容易被忽略的是日志和临时文件目录 —— 如果所有环境都往 /var/log/app 写，会混在一起，查问题时根本分不清是谁的日志。
