主干开发是一种版本控制管理实践。开发人员将小的、频繁的更新合并到核心“主干”或”主分支“。由于它简化了合并和集成阶段，因此有助于实现 CI/CD 并提高软件交付和组织绩效。


在软件开发的早期，程序员没有现代的版本控制系统。相反，他们只能同时开发两个版本的软件，作为跟踪变更并在必要时回退它们的手段。随着时间的推移，这显然是劳动密集型的、成本高昂且效率低下的。 

随着版本控制系统的成熟，出现了各种开发风格，使程序员能够更轻松地发现错误，与同事并行编码，并加快发布节奏。今天，大多数程序员利用两种开发模型中的一种来交付高质量的软件：Gitflow 和主干开发。 

最先流行的Gitflow是一种更严格的开发模型，只有某些人可以批准对主要代码的更改。这可以保持代码质量并最大限度地减少错误数量。主干开发是一种更加开放的模型，因为所有开发人员都可以访问主要代码。这使团队能够快速迭代并实施CI/CD。

什么是主干开发？

主干开发是一种版本控制管理实践，其中开发人员将小的、频繁的更新合并到核心“主干”或”主分支“。这是DevOps团队的常见做法，也是DevOps生命周期的一部分，因为它简化了合并和集成阶段。事实上，主干开发是CI/CD的必须实践。与其它具有长生命周期的功能分支策略相比，开发人员只会通过少量提交来创建短期分支。随着代码仓复杂性和团队规模的增长，主干开发有助于保持生产版本的流畅。

Gitflow vs. 主干开发

Gitflow是另一种Git分支模型，它使用长期存在的功能分支和多个主分支。与主干开发相比，Gitflow 拥有更多、更长生命周期的分支和更大的提交。在这个模型下，开发者创建一个功能分支，并直到功能开发完成才合并到主干分支。这些长期存在的功能分支需要更多的协作才能合并，因为它们与主干分支差异更大，引入冲突代码的风险更高。 

Gitflow还具有各种分支用于开发、修复缺陷、新功能和发布等。合并这些分支之间的提交有不同的策略。由于有更多的分支需要处理和管理，因此通常会有更多的复杂性，需要额外的计划会议和团队的审查。 

主干开发要简化得多，因为它专注于作为修复和发布的主分支。在主干开发中，假设主分支总是稳定的，没有问题，并且可以立即部署。

主干开发的好处

主干开发是持续集成的必须实践。如果构建和测试过程是自动化的，但开发人员在独立的、冗长的功能分支上工作，这些分支很少集成到共享分支中，那么持续集成就没有发挥出潜力。

主干开发减轻了代码集成的摩擦。当开发人员完成新工作时，他们必须将新代码合并到主分支中。然而，在他们确认可以成功构建之前，他们不应将变更合并到主干。在此阶段，如果自新工作开始后其他同事进行了修改，则可能会出现冲突。特别是，随着开发团队的成长和代码仓的扩展，这些冲突变得越来越复杂。当开发人员创建偏离源分支的单独分支并且其他开发人员同时合并重叠代码时，就会发生这种情况。主干开发模型很好地减少了这些冲突。

持续的代码集成

在主干开发模型中，有一个代码仓，有源源不断的代码提交合并到主分支。为处理频繁的代码合并请求，必须通过自动化测试和代码覆盖率检测来实现持续集成。当新代码合并到主干中时，会运行自动集成和代码覆盖测试来验证代码质量。

持续的代码审查

主干开发的快速、少量提交使代码审查成为一个更有成效的环节。通过小分支，开发人员可以快速查看和审查小的更改。与长期存在的功能分支相比，评审人员不需要阅读整页代码或手动检查大面积的代码更改，主干开发时的代码评审要简单有效得多。

持续的代码发布

代码应该每天频繁地合并到主分支。主干开发努力保持主干分支“绿色”，这意味着它可以随时部署。自动化测试、代码覆盖测试和代码审查为主干开发项目提供了随时部署到生产环境的保证。这使团队可以设定每日生产版本的目标，并能够灵活地频繁部署到生产环节。

主干开发和 CI/CD

随着CI/CD越来越流行，分支模型被细化和优化，导致主干开发兴起。现在，主干开发成为持续集成的需求。通过持续集成，开发人员执行主干开发，并结合自动化测试，可以确保每个代码提交合并到主干之后，项目始终平稳。

主干开发最佳实践

主干开发可确保团队快速、一致地发布代码。以下是最佳实践的列表，它们将有助于改进您团队的节奏并优化发布计划。

小批量开发

主干开发以快节奏将代码交付到生产环境。如果主干开发像音乐一样，那就是快速的断奏：快速连续的短而简洁的音符，代码仓提交就是音符。保持提交和分支较小可以加快合并和部署的速度。 

几次提交的小改动或几行代码的修改可以最大限度地减少认知开销。在可控的视觉区域进行代码审查，团队更容易进行有意义的对话并快速做出决定，不要在代码评审时面对庞大的代码变更集。

Feature flags（功能开关）

功能开关巧妙地配合了主干开发策略。开发人员将新代码封装在非活跃代码块中并在以后激活它。这样开发人员就无需创建单独的功能分支，而是将新功能代码直接提交到主分支，只是这些新代码由功能开关来控制。 

功能开关鼓励小批量更新。与创建功能分支并等待完整构建不同，开发人员创建一个引入功能开关的提交，然后推送到主分支，就可以在功能开关控制下完成功能构建。

全面的自动化测试

任何打算实现CI/CD的现代软件项目都需要自动化测试。有多种类型的自动化测试在发布流水线的不同阶段运行。在开发期间和代码合并时执行短期运行的单元和集成测试。运行时间更长的全栈端到端测试在针对完整的预生产或生产环境的后期管道阶段运行。

自动化测试通过在开发人员合并新提交时保持小批量节奏来支撑主干开发。自动化测试会检查代码是否存在任何问题，并自动批准或拒绝它。这有助于开发人员快速创建提交并通过自动化测试运行它们，以便查看它们是否引入了任何新问题。

执行代码评审

在主干开发中，代码评审应该立即进行，而不是放到异步系统中供以后审查。自动化测试完成了初级的自动化代码审查。当评审人员准备审查团队成员的新代码时，他们可以首先检查自动化测试是否通过以及代码覆盖率是否增加。这让评审者立即确信新代码符合某些规范。然后，评审者可以专注于人工优化。

代码仓中不超过三个分支

分支合并后，最好将其删除。具有大量分支的代码仓会产生副作用。虽然通过查看分支可以看到团队正在进行哪些工作，但如果存在陈旧和不活跃的分支，这种好处就会丧失。一些开发人员使用Git用户界面，当加载大量远程分支时，这些界面可能变得难以处理。

每天至少合并到主干一次

高效的主干开发团队应该至少每天处理一次可合并的分支。此实践有助于保持开发节奏并带动发布节奏。然后，团队可以在一天结束时将主干打上Tag，作为可发布的提交，这也带来了生成每日敏捷发布增量的效果。

减少代码冻结情况

敏捷的CI/CD团队不应该在集成阶段需要有计划的代码冻结或暂停，尽管组织可能出于其它原因需要冻结代码。CI/CD 中的“C（Continuous，持续）”意味着更新是不断流入的。主干开发团队应尽量避免代码冻结，并相应地进行计划以确保发布管道不会停滞。

快速构建并立即执行

为了保持快速的发布节奏，应该优化构建和测试执行时间。CI/CD构建工具应该在适当的地方使用缓存，以避免重复计算。如果用到第三方服务可以引入适当的模拟器来优化测试。

综上所述...

主干开发目前是高效工程团队的标准，因为它通过使用简化的Git分支策略来带动和保持软件发布节奏。此外，主干开发为工程团队如何向最终用户交付软件，提供了更多的灵活性和控制力。