我正在使用TFS设置DevOps流程，并对分支策略感到疑惑 . 如果我有以下样本分支（图像来自Guidance: A Branching strategy for Scrum Teams） .
我通过MAIN分支（与Jenkins）的持续集成设置了DevOps流程（持续集成和持续交付） .
- 如何处理修补程序？如果开发人员经常合并到MAIN分支以验证构建，那么如何获取上次发布的应用热修复代码？如果我使用Release分支，我最终必须将热修复集成到MAIN分支以启动CI过程 . 但是，MAIN分支可能包含发布之外的更改 .
请就此问题提出建议 .
6 回答
通常，热修复应该从主分支上的相关版本中获取 . 然后需要为hotfix创建一个专用分支，将其与最后一个stable分支合并 . 如果它通过整个QA，单元测试，系统测试等，则将其合并回主分支作为下一个发布版本 .
您可以在使用git时查看以下示例，引用位于：git best practice . 源代码控制不是问题，而是主要思想 . 仔细阅读文章我相信你将能够找到你想要的东西 .
还有一些组织仍在使用补丁......我对这个解决方案并不是很有趣，但如果这是你的情况而不是让我知道，因为在补丁中有一些不同的解决方案 .
建议让所有分支始终保持同步 . 如果要处理修补程序，可以从main创建新分支“HotFix” . 完成修补程序后，您需要将它从HotFix合并到Main，并从Main合并到Release .
如果您在版本中进行了任何更改，则需要将其合并回Main以完成更改 .
修补程序是已发布软件的修补程序 . 如果你有一个发布分支，那么从中创建一个修补程序分支是合适的 . 在将该修补程序提升为Prod之后，您可以反向集成备份链到Main . 修补程序 - >发布 - >主要，甚至可以根据需要将其集成到下一个sprint中 .
显然，您选择的答案取决于您的特定要求;但是，通常，您应该从main中删除一个版本，并从发布分支中删除一个热修复 . 就个人而言，我会说该代码不应该回到发布分支，而是在开发分支中进行双重修复 .
这样做的主要原因是，一旦您发布了代码，该代码分支就应该像发布时一样被锁定 . 如果你遵循这个，那么你总是可以回到以前的事态 . 正如已经建议的那样，当需求或优先级发生变化时，您可能会对修补程序进行一半的更改;或当客户报告实时代码中的错误时 . 如果您维护一个单独的分支，则始终可以访问该代码 .
如何处理这取决于您的发布和维护策略或客户协议 .
如果你的发布分支也是一个维护代码行（它似乎来自你的描述）然后从它创建功能分支，实现一个热修复，测试，合并并释放一个“补丁” . 理想情况下，您还应该为“维护”分支设置CI . 在此之后，您可以将hot-fix与主代码行集成，或者将问题放在backlog上，以便为将来的新版本实现不同的功能 .
顺便说一句：这里有一些不错的文章：https://www.cmcrossroads.com/article/agile-perspective-branching-and-merging和http://www.bradapp.com/acme/branching/branch-creation.html
如果您使用敏捷，那么功能分支可能是一个不错的选择 . 唯一的问题是它必须与JIRA或AGM等票务工具结合使用 . 为了处理此类场景中的修补程序，您可以在AGM或JIRA中创建用户素材，完成后将合并到主线干线上 .