我正在使用TFS设置DevOps进程并想知道分支策略。如果我有以下样本分支（图片来自Guidance: A Branching strategy for Scrum Teams）。DevOps中的分支策略
我的DevOps处理建立与持续集成从主分支（具有詹金斯）（持续集成和连续递送）。
请告知这个问题。
建议让所有分支机构始终保持同步。当您想要处理修补程序时，可以从main创建一个新的分支“HotFix”。修补程序完成后，您需要将修补程序从HotFix合并到Main，并从Main合并到Release。
如果您在发布中进行了任何更改，您需要合并到Main以完成更改。
修复程序是发布软件的修补程序。如果你有一个发布分支，那么创建一个修补分支是合适的。在将修补程序升级为产品之后，您可以将产品链反向集成到Main中。修补程序 - >发布 - >主要，甚至可以将它们整合到下一个sprint中，如果需要的话。
显然，您选择的答案取决于您的特定要求;但是，通常情况下，应该从主分区中释放一个释放，并从释放分支中释放一个热修复。就我个人而言，我会说这些代码不应该回到发布分支，而是在开发分支中进行双重修复。
这样做的主要原因是，一旦你释放了代码，该代码分支应该像发布时一样被锁定。如果你遵循这一点，那么你总是可以回到以前的事态。正如已经提出的那样，当需求或优先级发生变化时，您可能会修改一个修补程序;或者当客户报告实时代码中的错误时。如果您维护一个单独的分支，您可以随时访问该代码。
通常，修补程序应从主分支上的相关版本中取出。 然后需要为热修复程序创建一个专用分支，将其与最后一个稳定分支合并。 如果它通过了整个QA，单元测试，系统测试等，然后将它合并回主分支作为下一个发布版本。
你可以看看下面的例子，当使用git的时候参考这里：git best practice。源控制不是问题，而是主要想法。仔细阅读文章，我相信你能找到你要找的东西。
还有一些组织仍在使用补丁... 我不是一个很有趣的解决方案，但如果这是你的情况，不要告诉我，因为在补丁中有一点点不同的解决方案。
如果您使用的是敏捷，那么功能分支可能是一个不错的选择。唯一的是它必须与JIRA或AGM等票务工具结合使用。为了在这种情况下处理修补程序，您可以在AGM或JIRA中创建用户故事，完成后将合并到主线主干上。
为什么需要与其他产品关联？ TFS在跟踪工作项目方面做得很好。 –
我明白，这只是一个可能的例子。 –
如何处理这个问题真的取决于您的发布和维护策略或客户协议。
如果您的发布分支也发生维护代码行（看起来像您的描述），然后从它创建功能分支，实施热修复，测试，合并回来并发布“修补程序”。理想情况下，您应该为“维护”分支设置CI。 之后，您可以将热修复与主代码集成，或将积压问题放在未来的新版本中以不同的方式实施。
BTW：一些不错的文章在这里： https://www.cmcrossroads.com/article/agile-perspective-branching-and-merging 和 http://www.bradapp.com/acme/branching/branch-creation.html
如果开发商往往合并到主会发生什么？假设在sprint 2的中间，在prod中发现了一个bug，但是随着开发的进展，开发人员几次合并为主sprint 2代码。现在，构建从主分支开始，所以修补程序将进入主体以便构建和部署。您将如何使用DevOps处理这种情况？ – erdinger