Gitflow 发布标记模型造成困境

Question

我希望在工作中实现 gitflow 分支模型，正如在 http://nvie.com/posts/a-successful-git-branching-model/ 中首次提出的那样或在 Atalssian 网站 https://www.atlassian.com/git/workflows#!workflow-gitflow .不过有一件事困扰着我，我正在寻求澄清。一旦我们有了一个发布分支并认为它准备好了，我们就将它交付给 QA。他们进行测试，并在错误报告和修复之间反复进行，最后我们到达了从发布分支交付给 QA 的地步，他们接受了它，因此它已准备好发布。在这一点上，我认为你会

a) 运送与生产接受的完全相同的构建

b) 标记完成此构建的 git repo 代码，它将指向发布分支的末尾

c) 做其他簿记工作以将发布分支 merge 回 dev 和 master

相反，gitflow 建议我们执行上面的 c) 并标记 master 分支。这意味着要么

a) 我们在上面 a) 中运送到生产环境的构建与标签指向的代码不完全对应

或

b) 或者我们从新标记的 master 分支做一个新的构建并发布它，但这意味着我们发布的内容与 QA 测试和接受的内容不完全一致，它是一个新的构建

这两个看起来都不好。有没有人遇到过类似的想法？您实现了什么解决方案。

谢谢。

Answer 1

提交进入 master 的唯一方法是包含在发布分支或修补程序中。修补程序 merge 到发布分支¹。因此，当您执行将发布分支 merge 到 master 时，它应该是一个微不足道的 merge ，并且会生成与发布分支中相同的树。

要验证这一点，您可以执行 git diff release master(或等效地，git diff master^2 master，即将 master 分支上的 merge 提交与它的第二个父级，这是你的发布分支的尖端)。

[1] 这是一种特殊情况，仅在文本中内联提及，而不是在标题中提及，并且可能不会在 git 流自动化脚本中实现。