基于主干的开发是实践持续集成和持续交付/部署 (CI/CD) 的团队经常使用的几种分支策略之一。
通过基于主干的开发，您可以将更改直接提交到 master 分支（又称主干），而不是在单独的分支中开发功能或错误修正并在后续阶段将它们合并到 master 分支。
将更改提交到 master 分支会触发 CI/CD 管道。 如果管道标记了任何故障，那么每个人都有责任尽快尝试将其修正。 这样做的目的是保持 master 分支处于可部署状态，同时经常发布更改。
如果您已经熟悉 CI/CD 的原则，那么您可能已经从前面的描述中认识到，基于主干的开发非常适合持续集成和部署。 只要团队中的每个人都定期提交他们的更改，您就可以从看到每个人的更改以及对正在构建的内容的定期、快速反馈中受益。
保持 master 分支健康并处于可发布状态的首要任务会鼓励每个人随时为他们的更改添加测试。 监控测试覆盖率指标将帮助您密切关注这一点，同时确保每个人在提交之前都在本地构建（可能还运行一组基本的自动化测试）将减少在 master 分支上发现的问题数量。
一些基于主干的开发的拥趸认为，这是实现持续集成的唯一方法，使用开发或功能分支只会削弱 CI/CD 的好处。 但是，基于主干的开发也有其缺点。
虽然它非常适合持续部署（通过管道所有阶段的代码更改会自动发布），但该模型最适合 SaaS 产品，这种产品对持续更新（甚至是预期）有很高的容忍度。
如果您正在构建安装式产品或移动应用，则可能希望将更改批量应用到定期发布中，而不是为经过管道的每个更新创建一个新版本。
在这种情况下，使用分支可以更轻松地管理每个发布中包含的内容，并且为多个产品版本提供持续支持。
基于主干的开发的一个潜在挑战涉及如何处理大型或复杂功能的开发。 要在将更改定期提交到 master 分支的同时将这些更改直接部署到生产，需要一种方法来管理您还不想让用户看到的功能。
对于基于主干的开发，功能标志提供了一种控制功能可见性的方法，但管理这些功能可能相当复杂。 另一种方法是选择包含功能分支的分支策略，这样您就可以在准备发布功能前将其保持分离状态。
对于第一次使用 CI/CD 的团队，在您有时间开发可靠的测试套件之前，将更改直接提交到 master 分支并保持其可部署可能极具挑战。 如果基于主干的开发是一个很好的选择，那么随着 CI/CD 做法的成熟，将其作为您可以努力实现的目标是值得的。
基于主干的开发非常适合持续集成和部署，如果您拥有可靠的自动化测试套件，并且不需要支持软件的多个版本或将更新分组到发布中，那么这种开发会发挥最佳效果。 不过，这当然不是唯一的方法，其他分支策略可能会更符合需求，具体取决于您的情况。