我很难理解促进构建（及其构件）的概念如何与GitFlow一起工作。我正在与Git，Jenkins和（作为新成员）Artifactory制定一个持续的集成/交付工作流程。到目前为止，这是我得出的结论：
develop分支的构建工件将被自动推送到dev存储库（如果通过了单元测试等），因此被提升为dev状态。这些产品无法进一步提升。feature分支中的工件完全不会被推送或提升。release分支中的工件也只能提升为dev（或者我应该引入release回购吗？）release合并到master中后，将标记新提交，并且Jenkins将运行完整的CI / CD管道。经过单元测试和度量（在所有分支上运行的构建阶段）后，工件被推送到master仓库中，并被提升到master。然后，将工件用于部署到登台环境中，在该登台环境中可以进行最终测试（这些测试可以在完整的连续部署设置中自动进行）。如果所有测试均成功，则工件将被推送到prod存储库，部署到生产环境并提升为prod状态。如果直到生产失败的任何阶段，该标签都属于一个从未投入生产的版本。我的理解正确吗？我对主/发行版合并大为困惑。直观地说，release中的二进制文件将经过最多的测试。但是，GitFlow规定仅对master上的提交进行标记（并且我不想标记从技术上讲不会生成要在生产中运行的二进制文件的提交）。如果在master上的提交构建期间发现问题怎么办？有没有进入生产的标签是“错误的”吗？我是否必须还原或撤消标记，甚至合并提交？
很高兴听到其他人参与此构建促进+ GitFlow的工作。非常感谢您的帮助。
答案 0 :(得分：0)
有太多不同的分支模型，并且有很多人有自己的选择，我认为“ GitFlow”的含义没有明确的参考。 （请随时证明我错了，我喜欢辩论这种事情。）
话虽如此，我（个人）发现这两个参考文献非常有帮助，完整和令人信服：
那又怎样？
我认为您的前两点是正确的，而后两点是错误的。
从构建促进的角度来看，所有release和hotfix分支机构都可以（并预期）部署到您的test / staging环境中进行最终验证。来自DataShift：
release分支中的代码被部署到合适的测试环境中，经过测试，任何问题都直接在release分支中解决。这种部署->测试->修复->重新部署->重新测试周期一直持续到您满意该发行版本足以向客户发行为止。
然后，一旦一切都经过验证，您就可以发布了：
发行完成后，发行分支也将合并到master和development中，以确保新发行不会意外丢失对发行分支所做的任何更改。
或者，总结一下：
master分支仅跟踪已发布的代码。对master的唯一提交是来自发行分支和修补程序分支的合并。
这是棘手的地方，不同的项目有不同的看法：prod工件实际上是哪里来的？
如我所见，您有两种选择：
test / staging分支构建的release / hotfix中的工件。master中的提交重新构建工件。从仅代码的角度来看，它们是等效的-master中的代码与刚构建并部署到test / staging的代码完全匹配。但是，从构建过程角度来看，情况可能会有所不同-不同的环境变量，不同的键等。
此外，您的团队如何看待test和staging可能会使事情变得复杂。
那该怎么办？
请注意，这只是我的观点，并假设staging表示“生产镜像”，我认为以下是一个明智的过程：
dev环境（如果存在）是从develop分支构建/部署的。test环境是从release或hotfix分支构建/部署的。staging或release分支构建/部署hotfix环境。注意：您可以使用RC标记来表明这一点，但这是团队过程中的问题。staging验证完成后，代码从release / hotfix合并到master，并用发行版标记。prod环境与来自staging的经过批准和测试的工件一起部署。最终想法：
GitFlow是一个不错的起点，但是您最终将根据自己的需要对其进行自定义。不要害怕说“这对我们的团队有效”，并以您自己的方式来做-只需确保将其写下来，以便所有人都知道您的工作方式即可。