本文目标 了解不同的分支开发模式并给出自己的理解 为熟练掌握并选择不同的分支开发模式做准备

参考资料 Link to heading

按照官方的分类就比较简单:

  • 长期分支:分支将长期存在,不同分支之间的区别将是稳定性的区别。其中master最稳定,dev比较不稳定,topic次之。
  • 短期分支:除了master外不存在长期分支,所有分支都将短期存在,目标为实现一种主题(单一的特性或工作)。实现完成之后就合并到master中

阿里的分支模式分类就更接近生产,除了强调开发外也强调发布。

  • TBD(主干开发模式),有点类似长期分支,但是比长期分支简单很多。最简单的版本就是所有团队成员共有一个开发分支,这样的问题在于如果团队变大的话,每天各个成员光是在合并提交上就会花费很多时间。因此要求每次变更提交都要足够小,且能快速完成验证。
  • 特性分支开发模式(Git-Flow):这个是真的有点类似Git官方中长期分支与短期分支的结合。就每一个特性来说,所有关于该特性的开发工作都会集中在一个分支上,当完成该特性的工作之后,再把特性分支合并回代码主路径上并准备发布
    • 长期存在着多个分支,比如feature分支(功能开发)、develop(功能集成)、release(版本发布)、hotfix(线上修改)、master(最新已发布版本基线)
    • 每个特性都在对应的feature分支上开发。特性开发完毕并验证通过后会merge到develop分支(大部分时间都与master接近)进行集中验证。然后验证完毕之后单独拉到release分支进行发布。中间的任何错误都会从release分支往回传,其中master分支永远是最新的可运行分支。
    • 缺点:分支特别多,而且非常复杂。develop分支等的意义比较冗余(与master等相比)
  • Github-Flow,任务导向型,更贴近短期分支。实际上也是大部分开源项目所采用的方法。
    • master分支的所有代码都应该是最新的可部署、可工作版本
    • 新的工作从master拉取分支,并以工作任务进行命名
    • 完成任务后提交pull-request合并到master分支并提起代码评审,评审通过后进行合并。
  • Gitlab-Flow,将pull-request改为了merge-request,与Github-Flow非常相似
    • 最大的区别是发布侧,引入了对应生产环境的production分支和预发环境的pre-production分支。 Gitlab-flow