Git Jenkins将主分支或标记分支部署到生产中

我一直在为我的公司做一个内部项目，在此期间我一直在学习git和Jenkins。我有两个分支，发展和掌握。我将develope部署到一个develope服务器并进行测试，直到我满意为止。然后，我合并开发以掌握和标记带有语义版本控制（v1.0.0）的版本

---

我的问题是，当我想将代码发布到生产服务器时，我应该部署标记的分支（refs/tags/v1.0.0）还是主分支。是否有最佳实践或哪种实践是最佳的争论？

根据持续交付实践，您需要遵循一次构建-到处部署规则：

在CI服务器上的构建步骤中，您将创建一个二进制文件。然后将其部署到测试所需的任何服务器上

测试完所有内容后，您将部署与测试相同的二进制文件。您不需要从另一个具有另一个版本的分支创建另一个二进制文件

否则，您测试的内容和您发布给PRD的内容可能是不同的二进制文件。风险通常很小，但却是真实的。通常，它来自于CI作业的糟糕配置（正确的配置实际上并不那么容易），但也可能来自于管理依赖项的服务器中的更改（对于Java，这些是Nexus、Artifactory）或CI服务器上的升级

---

因此，您不应该从标记或主控创建新构建。虽然您可以摆脱开发分支，直接在master中工作，但这样您就可以从master中释放。如果需要，标记仍然是一个选项。

我遵循Atlassian git流模型，其中维护了develop和master。如果我正在测试开发分支，那么我将开发分支合并到master，理论上它将是一个精确的副本。我通过Jenkins部署python，因此不需要二进制版本。我正在学习git标记，不确定我发布到生产服务器的内容（master/git标记分支）。我想我还没有完全理解标记，我知道这是一个冻结回购状态的时间点。所以有人会认为这就是您想要部署的，但是我没有找到太多文档。GitFlow是一种非常（！）过时的分支方式。我甚至不确定它最初被描述时是否与现代实践同步。即使您要遵循GitFlow（您应该从原始文章中阅读，而不是阅读Atlassian:），您也应该从

release

分支发布，然后将其合并到

master

。至于标记，它们只是指向提交的指针。与分支相同（但分支在提交之间移动，而标记保持静止）。标记/分支没有那么重要-提交、blob和树都很重要。谢谢，你有一个指向我可以遵循的现代分支/部署方式的链接吗？这样的链接存在吗？或者这是随着时间的推移而学习的？CI/CD建议所谓的基于主干的开发，互联网上有很多好的资料，注意通过抽象和功能切换进行分支。一开始可能太过极端，但不妨尝试一下。你可以读CD上的原著（尽管它非常重复，因此有点无聊）：