Tfs DevOps中的分支策略

我正在用TFS设置DevOps进程，并想知道分支策略。如果我有以下示例分支（来自的图像）

我已经建立了DevOps流程（持续集成和持续交付），并从主分支（与Jenkins）进行了持续集成

• 我如何处理修补程序？如果开发人员经常合并到主分支以验证构建，那么如何获得应用热修复程序的最新发布代码？若要使用发布分支，我最终必须将热修复程序集成到主分支中，以便启动CI过程。但是，主分支可能包含版本之外的更改

---

请就此问题提供建议。

建议您始终同步所有分支。当您想要处理修补程序时，您可以从main创建一个新的分支“修补程序”。当修补程序完成后，您需要将其从修补程序合并到主版本，并从主版本合并到发布版本

---

如果您在发布版中进行了任何更改，则需要将其合并回Main以最终确定更改。

热修复程序是发布软件的修补程序。如果您有一个发布分支，那么在它的基础上创建一个热修复分支是合适的。在该修补程序升级到Prod之后，您可以将该链反向集成到Main。热修复->发布->主，甚至在需要时将其向前集成到下一个sprint

显然，你选择的答案取决于你的特殊要求；但是，通常，您应该从main中剪切一个版本，并从发布分支中剪切一个热修复程序。就个人而言，我想说的是，代码不应该回到发布分支，而应该在开发分支中进行双重修复

---

这样做的主要原因是，一旦您发布了代码，该代码分支应该像发布时一样被锁定。如果你遵循这一点，那么你总是可以回到以前的状态。正如已经提出的，当需求或优先级发生变化时，您可能正在修改修补程序的中途；或者当客户报告实时代码中的错误时。如果您维护一个单独的分支，则始终可以访问该代码。

通常，热修复程序应该从主分支上的相关版本中发出。 然后需要为热修复程序创建一个专用分支，将其与最后一个稳定分支合并。 如果它通过了整个QA、单元测试、系统测试等，那么将其合并回主分支作为下一个发布版本

当使用git时，您可以查看以下示例。引用位于此处：。源代码管理不是问题，而是主要思想。仔细阅读这篇文章，我相信你会找到你想要的

有些组织仍在使用修补程序。。。

---

我对这个解决方案不是很感兴趣，但如果是你的情况，请告诉我，因为在补丁中有一个稍微不同的解决方案。

如果你使用的是敏捷，那么功能分支是一个不错的选择。唯一的问题是，它必须与JIRA或AGM等票务工具相结合。对于在这种情况下处理修补程序，您可以在AGM或JIRA中有一个用户故事，完成后将合并到主线主干上。

如何处理这一问题实际上取决于您的发布和维护策略或客户协议

如果您的发布分支碰巧也是一个维护代码行（从您的描述来看似乎是这样），那么就从中创建特性分支，实施热修复、测试、合并并发布“补丁”。理想情况下，还应该为“维护”分支设置CI。 在此之后，您可以将热修复程序与主代码行集成，或者将问题放在backlog上，以便在未来的新版本中以不同的方式实现它

顺便说一句：这里有一些不错的文章： 和

---

如果开发人员经常合并到主应用程序中，会发生什么情况？比方说，在Sprint2的开发过程中，prod中发现了一个bug，但随着开发的进行，开发人员多次将Sprint2代码合并到主代码中。现在，构建是从主分支开始的，所以热修复程序必须进入主分支才能构建和部署。对于DevOps，您将如何处理这种情况？为什么需要与其他产品关联？TFS在跟踪工作项方面做得很好。我知道，这只是一个可能的示例的说明。