我正在寻找在工作中实现gitflow分支模型，首先在http://nvie.com/posts/a-successful-git-branching-model/或在https://www.atlassian.com/git/workflows#!workflow-gitflow的Atalssian网站上进行。有一件事困扰我，我正在寻求澄清。一旦我们有一个发布分支并认为它准备就绪，我们将其交付给QA。他们进行测试并且有一些来回的错误报告和修复，最后我们达到了一个点，我们从发布分支交付QA并且他们接受它，所以它准备发布。在这一点上，我认为你会
a）运送与生产接受的完全相同的构建
b）标记完成此构建的git repo代码，该代码将指向发布分支的末尾
c）执行其他簿记以将发布分支合并回dev和master相反，gitflow建议我们在上面做c）并标记主分支。这意味着
a）上面a）中我们发布到生产的版本与标签指向的代码不完全对应
或
b）或者我们从新标记的主分支机构进行新的构建并发布，但这意味着我们发布的内容与QA测试和接受的内容不完全对应，它是一个新版本
这两个看起来都很糟糕。有没有人遇到类似的想法？你实施了什么解决方案。
感谢。
答案 0 :(得分：3)
提交进入master的唯一方法是包含在发布分支或修补程序中。并且修补程序合并到发布分支 1 中。因此，当您将发布分支合并到master时，它应该是一个简单的合并，并且与发布分支中的结果相同。
要验证这一点，您可以执行git diff release master（或等效地，git diff master^2 master，即在主分支上使用其第二个父级（即发布分支的提示）区分合并提交。
[1]这是一个特殊情况，只在文本中提及，而不是在标题中提及，并且可能无法在git flow自动化脚本中实现。