如何将Git项目部署到两个不同的Heroku测试/生产服务器

嘿，我来帮你梳理下这两个方案的优劣，以及适合你的最佳实践方向~

先明确核心原则 #

Heroku官方推荐的多环境部署思路，是用不同的远程仓库对应不同环境，同时配合清晰的分支策略，既能隔离测试和生产的代码变更，又能降低误操作风险。

方案一：双分支（test/prod）对应双环境 #

这是更规范、风险更低的主流方案，尤其适合需要严格区分测试和生产代码的场景：

• 优势：
  • 分支隔离清晰，测试分支可以放心做迭代、调试，不会影响生产环境的稳定代码；
  • 变更路径可控：只有测试验证通过的代码，才通过合并（比如Pull Request）同步到生产分支，能有效拦截问题；
  • 环境变量不用在代码里折腾：你提到的每次合并改.env里的environment变量其实没必要——直接用Heroku自带的环境变量配置就行，完全不用动代码！
• 实操步骤：
  1. 先给本地仓库添加两个Heroku远程：

     # 添加测试环境远程
     heroku git:remote -a heroku-test
     git remote rename heroku heroku-test
     # 添加生产环境远程
     heroku git:remote -a heroku-prod
     git remote rename heroku heroku-prod
     

  2. 推送分支到对应环境：

     # 推test分支到测试环境的主分支（比如main）
     git push heroku-test test:main
     # 推prod分支到生产环境的主分支
     git push heroku-prod prod:main
     

  3. 设置环境变量（不用改代码）：

     # 给测试环境设置environment=test
     heroku config:set environment=test -a heroku-test
     # 给生产环境设置environment=prod
     heroku config:set environment=prod -a heroku-prod
     

• 注意事项：
  合并test到prod时，建议用Pull Request做代码审查，确保没有冲突和问题；如果团队协作，还可以在PR里加上测试通过的标记，更严谨。

方案二：单master分支推送到两个环境 #

这个方案适合代码变更频率低、团队规模小的场景，但风险相对较高：

• 优势：不用维护多个分支，代码只有一份，减少分支管理的琐碎工作；
• 劣势：
  • 风险高：同一分支的代码同时对应两个环境，一旦不小心误推，很容易把未测试的代码直接弄到生产；
  • 灵活性差：如果测试需要临时加调试代码，会直接影响到生产分支的纯净度，要么得临时切分支，要么就得冒着风险不推送生产；
• 实操步骤：
  1. 添加两个远程仓库：

     git remote add heroku-test https://git.heroku.com/heroku-test.git
     git remote add heroku-prod https://git.heroku.com/heroku-prod.git
     

  2. 推送时指定目标分支：

     # 推master到测试环境的test分支
     git push heroku-test master:test
     # 推master到生产环境的prod分支
     git push heroku-prod master:prod
     

  但还是那句话，环境变量别在代码里改，用Heroku的config:set命令设置更安全。

我的最佳实践推荐 #

优先选优化后的方案一，原因如下：

1. 分支隔离能最大程度降低生产环境的风险，这是企业级部署的核心要求；
2. 用Heroku环境变量替代代码里的.env修改，避免了合并时的冲突，也更符合12-factor应用的配置规范；
3. 如果你想更高效，可以搭配Heroku的Pipeline功能：把test和prod环境组成流水线，测试通过后直接点击「Promote」就能把测试环境的镜像升级到生产，连代码合并都省了，完全避免了手动合并可能带来的错误。

内容的提问来源于stack exchange，提问作者DeLac