Git分支开发模式学习

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

参考资料

• segmentationfault
• official-分支开发工作流

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

• 长期分支：分支将长期存在，不同分支之间的区别将是稳定性的区别。其中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分支。