我知道这个问题已经被问过很多次了，但我仍然希望在这里再次得到答案并提供一些解释。
所以我知道 Github 流程只是告诉你使用 master 和 feature 分支。
只要我们将某些内容合并到master，生产服务器就会更新。如果我也想拥有staging 环境怎么办？ Github 工作流如何处理这个问题？是不是说当某些东西合并到feature/* 分支时，它会更新暂存环境？但如果是这样的话，虽然有多个特性分支，但我们不能有 1 个暂存环境，这意味着每个特性分支都有自己独立的暂存环境，其他特性分支的代码不会结束。无论如何，如果是这样，我们就无法进行适当的 QA 测试来测试多个功能分支完成的所有工作。
知道我错过了什么吗？
【问题讨论】：
标签： git github continuous-integration gitlab continuous-deployment
首先，我建议彻底阅读https://trunkbaseddevelopment.com/（GitHub 流是 TBD 的子集），因为 TBD 工作流还有一些其他选项可能相关，即使用发布分支。
一旦我们将某些东西合并到主服务器中，生产服务器就会更新。
这不一定是真的，我认为您的困惑源于此陈述。我推荐的场景（尽管这里没有单一的方法）是有一个单独的部署存储库。因此，您有实际代码的存储库和另一个用于部署的 Git 存储库（GitOps 方式）。
然后，您的业务规则定义了不同环境之间的某种路由逻辑。在一天结束时，您的环境状态应该反映在部署存储库中。有一些工具可以自动化流程的不同部分（免责声明：我正在研究其中之一 - Reliza Hub）。
这里的重要一点是，您的主分支的特定提交首先被部署到测试或暂存，然后在该代码上完全完成测试，然后才将其部署到下一个环境并最终部署到生产环境。因此，您只需将之前在其他环境中看到的内容转移到生产环境中。主要的 QA 活动是在合并到 master 中的代码上完成的。
现在，关于功能分支 - 这些都是短暂的。大多数情况下，它们应该被自动化测试覆盖。在某些情况下（对于影响较大的更改），启动一个短期环境是有意义的，该环境将托管来自功能分支的代码并在此环境上进行一些手动测试。最后一种方法目前非常流行，但工具是高度定制的 - 通常需要时间来正确设置它。
最后，如果您使用发布分支，那么拥有一组以上的测试、登台等环境可能是有意义的。这取决于您的项目的规模和合规性要求。
【讨论】：