在使用git-flow时，是否可以/值得拥有“主”、“测试”和“开发”分支？

Question

我目前正在参与一个项目，我们正在迁移到Git。我们正试图确定使用哪种工作流程。我们非常喜欢git-flow，但有一个问题。

据我了解，按照git-flow的方式，开发人员会从develop分支创建feature分支，一旦他们完成特定的feature分支，代码就会合并到develop中。当我们想要发布到线上时，develop然后合并到master中。在我们的情况下，develop将是当前部署在我们的Dev环境中的内容，而master将是当前的Live。这很好。

问题

问题是我们还有另一个环境需要部署到Live之前，即Test。我们希望有一个test分支，它将始终代表当前部署到Test的内容。

我们设想这样工作：

1. 开发人员在feature分支中工作，将其合并到develop中，然后将其部署到Dev中。
2. 当我们准备升级到Test时，将develop合并到test中，并将其带到Test中。
3. 一旦在Test中全部签名完毕，我们将test合并到master中，然后将其带到Live中。

我的问题

1. 使用git-flow是否可能？如果可以，如何实现？
2. 我们应该这样做吗？
3. 还有其他方法可以实现吗？

- KernelKoder

---

测试并不是必要的。你可以将开发部署到一个暂存站点并进行签名。当这个过程完成后，你就可以将开发分支合并到主分支并推送主分支。如果test只是镜像develop，那么我认为没有太多必要保留test分支了。 - McNab

它确实为我们提供了价值，Dev用于开发所有新功能，开发人员可以确保他们的更改被正确集成。而Test是测试人员进行测试的环境。由于每次合并新功能时我们都会部署到Dev，这导致测试人员受阻。我们较少地部署到Test，以便保持环境稳定以进行测试。 - KernelKoder

Answer 1

git-flow有一个名为release的分支概念，可以用于此目的。

事实上，在git-flow中，develop不是简单地合并到master。您首先创建一个release分支，在其中准备现场版本，测试它，并在合并到master之前进行最后一分钟的错误修复，即将其发布。

当关闭release时，它也会合并回develop，因此您将拥有在测试期间完成的所有修复内容，并将其合并回主开发分支。

发布分支支持新生产发布的准备工作。它们允许最后一刻点缀i和穿过t。此外，它们允许进行轻微的错误修复并为发布（版本号、构建日期等）准备元数据。

— 成功的Git分支模型»nvie.com

- Hugo Ferreira

---

这肯定可行。如果我们在进入Live之前多次推广到Test，我想我们只需每次将develop中的内容合并到release分支中即可？ - KernelKoder

@KernelKoder 是的，我认为这样做应该没问题，尽管你必须小心一些，以免在“发布”分支中破坏错误修复。我可以看到在制作发布版本的过程中逐步测试新功能的用例，但我个人从未这样做过。请记住，在测试版本中修复错误（例如清除阻止测试的错误）应直接在“发布”分支中完成，以更轻松地跟踪该提交的性质，因此您必须注意在从那里拉取新功能之前将它们合并回develop。 - Hugo Ferreira

@KernelKoder 所以总的来说，我认为如果你更加严格地遵循“发布”分支的“规则”，那么你应该先手动关闭“发布”分支并将其合并回“develop”（但不是“master”，因为这相当于取消发布），然后再开启一个新的“发布”分支来测试新功能...但实际上，在我的git-flow使用中，我并不是太“纯粹主义者”，只要你理解了约束条件（例如没有任何错误修复的“发布”与有一些错误修复的“发布”之间的区别），你就可以根据每种情况选择最适合的方法。 - Hugo Ferreira

@HugoFerreira 在这个工作流程中，develop 的意义是什么？为什么不直接从 master 分支检出到一个新的 release 分支呢？（看起来 develop 只是在镜像 master 分支）。 - juanpazos

在 git-flow 方法中，develop 的目的是收集和基于正在开发的新功能分支。master 分支应该只包含表示当前版本的提交。因此，在工作中的 release 分支时，develop 将继续接收新功能以成为未来版本的一部分，而 master 分支只有在关闭发布分支后才会更改。 - Hugo Ferreira

关于 git-flow 的快速评论和更新：这个答案是在2015年，当时我正在使用打包软件（人们必须下载和安装的东西）。我仍然相信 git-flow 可以成为这种用例的良好方法。但从那时起，我一直在使用基于Web的软件，让我非常强调：git-flow 对于Web软件来说是一个可怕的选择。在Web软件中，总是只有一个版本对所有人生效。放弃额外开销并选择某种 https://trunkbaseddevelopment.com 的风格会更好。 - Hugo Ferreira