使用 GitFlow 构建推广究竟是如何工作的？
How exactly works build promotion with GitFlow?
我很难理解提升构建（及其工件）的概念究竟是如何与 GitFlow 一起工作的。我正在使用 Git、Jenkins 和（作为新添加的）Artifactory 制定连续的 integration/delivery 工作流程。这是我到目前为止所做的：
develop 分支的构建工件将自动推送到 dev 回购（如果单元测试等通过），因此提升到 dev 状态。这些工件无法进一步促销。- 来自
feature 个分支的工件根本不会被推送或提升。
- 来自
release 分支的工件也只能提升到 dev（或者我应该引入一个 release 仓库？）
- 一旦
release 合并到 master，新的提交就会被标记并且 Jenkins 运行 是完整的 CI/CD 管道。在单元测试和指标（在所有分支上 运行 的构建阶段）之后，工件被推送到 master 存储库并提升到 master。然后将工件用于部署到暂存环境，可以在其中进行最终测试（这些测试可以在完整的连续部署设置中自动执行）。如果所有测试都成功，工件将被推送到 prod 存储库，部署到生产环境并提升到 prod 状态。如果生产失败之前的任何阶段，该标签属于一个从未投入生产的版本。
我的理解对吗？我对 master/release 合并感到很困惑。凭直觉我会说，来自 release 的二进制文件将接受最多的测试。然而，GitFlow 规定只有在 master 上的提交才会被标记（我不想标记技术上不会产生生产中的二进制文件的提交）。如果在 master 上提交的构建过程中发现问题怎么办？是否 "wrong" 有标签，但没有投入生产？我是否必须还原或撤消标记甚至合并提交？
很高兴听到其他人对此构建推广的方法 + GitFlow 事情。非常感谢任何帮助。
有这么多不同的分支模型，这么多人有自己的看法，我认为没有关于 "GitFlow" 含义的明确参考。 （请随意证明我错了，我喜欢辩论这种事情）。
话虽如此，我（个人）发现这两个参考资料非常有帮助、完整且引人注目：
所以，什么？
在我看来，你的前两点是正确的，后两点是错误的。
从构建推广的角度来看，所有 release 和 hotfix 分支都有资格（并且预期）部署到您的 test/staging 环境以进行最终验证.来自 DataShift：
The code in the release branch is deployed onto a suitable test environment, tested, and any problems are fixed directly in the release branch. This deploy -> test -> fix -> redeploy -> retest cycle continues until you’re happy that the release is good enough to release to customers.
然后，一旦所有内容都经过验证，您就可以发布了：
When the release is finished, the release branch is merged into master and into develop too, to make sure that any changes made in the release branch aren’t accidentally lost by new development.
或者，总结一下：
The master branch tracks released code only. The only commits to master are merges from release branches and hotfix branches.
这就是它变得棘手的地方，不同的项目有不同的意见：prod 工件实际上来自哪里？
在我看来，你有两个选择：
- Re-use 来自
test/staging 的工件是从 release/hotfix 分支构建的。
- Re-build
master. 中提交的工件
从 仅代码 的角度来看，这些是等效的 - master 中的代码与刚刚构建并部署到 test/ 的代码完全匹配staging。但是，从 构建过程 的角度来看，事情可能会有所不同 - 不同的环境变量、不同的密钥等。
此外，您的团队如何看待 test 与 staging。
情况可能会变得复杂
那么，怎么办？
请注意，这只是我的意见，并且假设 staging 意味着 "production mirror"，我认为以下是一个明智的过程：
- 功能分支未部署到共享环境
dev 环境（如果存在）来自 develop 分支 built/deployedtest 环境来自 release 或 hotfix 分支 built/deployed staging 环境是 built/deployed 来自 release 或 hotfix 分支，正常 testing/fixing 完成后。注意：您可以使用 RC 标记来指明这一点，但这是一个团队流程问题。staging验证完成后，代码从release/hotfix合并到master，并标记发布版本。prod 环境部署了 staging 中批准和测试的工件。
最后的想法：
GitFlow 是一个很好的起点，但您最终要根据自己的需要对其进行自定义。不要害怕说 "this is what works for our team" 并按照自己的方式去做 - 只要确保将其写下来，以便每个人都能理解您的做法。
我很难理解提升构建（及其工件）的概念究竟是如何与 GitFlow 一起工作的。我正在使用 Git、Jenkins 和（作为新添加的）Artifactory 制定连续的 integration/delivery 工作流程。这是我到目前为止所做的：
develop分支的构建工件将自动推送到dev回购（如果单元测试等通过），因此提升到dev状态。这些工件无法进一步促销。- 来自
feature个分支的工件根本不会被推送或提升。 - 来自
release分支的工件也只能提升到dev（或者我应该引入一个release仓库？） - 一旦
release合并到master，新的提交就会被标记并且 Jenkins 运行 是完整的 CI/CD 管道。在单元测试和指标（在所有分支上 运行 的构建阶段）之后，工件被推送到master存储库并提升到master。然后将工件用于部署到暂存环境，可以在其中进行最终测试（这些测试可以在完整的连续部署设置中自动执行）。如果所有测试都成功，工件将被推送到prod存储库，部署到生产环境并提升到prod状态。如果生产失败之前的任何阶段，该标签属于一个从未投入生产的版本。
我的理解对吗？我对 master/release 合并感到很困惑。凭直觉我会说，来自 release 的二进制文件将接受最多的测试。然而，GitFlow 规定只有在 master 上的提交才会被标记（我不想标记技术上不会产生生产中的二进制文件的提交）。如果在 master 上提交的构建过程中发现问题怎么办？是否 "wrong" 有标签，但没有投入生产？我是否必须还原或撤消标记甚至合并提交？
很高兴听到其他人对此构建推广的方法 + GitFlow 事情。非常感谢任何帮助。
有这么多不同的分支模型，这么多人有自己的看法，我认为没有关于 "GitFlow" 含义的明确参考。 （请随意证明我错了，我喜欢辩论这种事情）。
话虽如此，我（个人）发现这两个参考资料非常有帮助、完整且引人注目：
所以，什么？
在我看来，你的前两点是正确的，后两点是错误的。
从构建推广的角度来看，所有 release 和 hotfix 分支都有资格（并且预期）部署到您的 test/staging 环境以进行最终验证.来自 DataShift：
The code in the release branch is deployed onto a suitable test environment, tested, and any problems are fixed directly in the release branch. This deploy -> test -> fix -> redeploy -> retest cycle continues until you’re happy that the release is good enough to release to customers.
然后，一旦所有内容都经过验证，您就可以发布了：
When the release is finished, the release branch is merged into master and into develop too, to make sure that any changes made in the release branch aren’t accidentally lost by new development.
或者，总结一下：
The master branch tracks released code only. The only commits to master are merges from release branches and hotfix branches.
这就是它变得棘手的地方，不同的项目有不同的意见：prod 工件实际上来自哪里？
在我看来，你有两个选择：
- Re-use 来自
test/staging的工件是从release/hotfix分支构建的。 - Re-build
master. 中提交的工件
从 仅代码 的角度来看，这些是等效的 - master 中的代码与刚刚构建并部署到 test/ 的代码完全匹配staging。但是，从 构建过程 的角度来看，事情可能会有所不同 - 不同的环境变量、不同的密钥等。
此外，您的团队如何看待 test 与 staging。
那么，怎么办？
请注意，这只是我的意见，并且假设 staging 意味着 "production mirror"，我认为以下是一个明智的过程：
- 功能分支未部署到共享环境
dev环境（如果存在）来自develop分支 built/deployedtest环境来自release或hotfix分支 built/deployedstaging环境是 built/deployed 来自release或hotfix分支，正常 testing/fixing 完成后。注意：您可以使用RC标记来指明这一点，但这是一个团队流程问题。staging验证完成后，代码从release/hotfix合并到master，并标记发布版本。prod环境部署了staging中批准和测试的工件。
最后的想法：
GitFlow 是一个很好的起点，但您最终要根据自己的需要对其进行自定义。不要害怕说 "this is what works for our team" 并按照自己的方式去做 - 只要确保将其写下来，以便每个人都能理解您的做法。