我很难理解促进构建（及其工件）的概念如何与 GitFlow 协同工作。我正在与 Git、Jenkins 和（作为新添加的）Artifactory 制定持续集成/交付工作流程。这是我迄今为止的工作：
develop分支的构建工件将自动推送到存储dev库（如果单元测试等通过）并因此提升为dev状态。这些工件无法进一步促销。feature分支的工件根本不会被推送或提升。release分支的工件也只能被提升到dev（或者我应该引入一个release回购？）release合并到 中master，新的提交就会被标记，Jenkins 就会运行完整的 CI/CD 管道。在单元测试和指标（在所有分支上运行的构建阶段）之后，工件被推送到一个masterrepo 并提升到master. 然后将工件用于部署到暂存环境，在那里可以进行最终测试（这些测试可以在完整的持续部署设置中自动化）。如果所有测试都成功，工件将被推送到一个prod仓库，部署到生产并提升到prod状态。如果在生产之前的任何阶段失败，则标签属于一个从未进入生产的版本。我的理解正确吗？我主要对主/发布合并感到困惑。直觉上我会说，来自的二进制文件release将接受最多的测试。然而，GitFlow 规定只有在master被标记时提交（我不想标记技术上没有产生进入生产的二进制文件的提交）。如果在构建提交期间发现问题master怎么办？拥有未投入生产的标签是“错误的”吗？我是否必须恢复或撤消标签甚至合并提交？
很高兴听到其他人对此构建推广 + GitFlow 的看法。任何帮助深表感谢。