如何在预发布环境中使用git flow？

Question

我们正在使用 git-flow 处理热修复和功能，具有开发分支和主分支（用于生产）。

最简单的方法是如何添加一个暂存分支以便验证从 develop 到 production 的工作，同时仍保留 git-flow 的实用性？

- Eric

Answer 1

我认为分段应该基于git flow release分支。在执行git flow release start和git flow release publish后，您可以在该分支上开始QA工作，包括将其部署到暂存区。当暂存区中的QA工作证明代码已准备好在生产环境中部署时，请在生产环境中进行部署并执行git flow release finish。

如果您正在使用TeamCity，则可以轻松设置服务器以检测新的远程发布分支，并自动为它们设置构建，在此处查看。

- Klas Mellbourn

---

你建议为每个潜在的发布版本使用不同的分支，而不是像开发和主分支一样有一个专门用于“正在测试的下一个发布版本”的分支。 - Eric

是的，据我所知，这将是标准的 git-flow 方式。你始终可以将分支命名为相同的名称，例如“staging”。但是，git-flow 的正常用法是在 git flow release finish 时删除分支，并在 git flow release start 时重新创建它。 - Klas Mellbourn

Answer 2

我刚开始使用git flow，但我认为最简单的方法是将“下一个发布”设置为“dev”分支，“生产发布”设置为“stage”分支，然后手动与“master”分支（你的实际生产）合并。

如果你将版本1.2.0发布到“stage”，然后发现了错误（例如核心CMS、feature1、feature3和feature4中的4个热修复），那么你总是可以应用补丁，这样你最终可以得到版本1.2.4，然后将其合并到生产环境。

更新：此方案假定你没有回滚机制，因此你总是在添加提交以修复问题、发布功能或其他操作。如果你有回滚机制，那么你不需要担心在生产环境中出现的错误。只需在发现错误时使用回滚来设置之前的工作版本。例如，如果你在版本1.2.3中发现错误，请返回到版本1.2.2。修复错误，在dev上进行测试，然后在stage上进行测试，并将其推送到生产环境作为版本1.2.4。因此，你的生产环境将直接从1.2.2跳转到1.2.4。

- sobi3ch