声明
近期公司组内对GIT管理进行规范,统一采用gitflow进行git管理,起初由项目经理讲解给我们组内听,后续个人感觉该流程及管理方式在社区也是比较火热的,所以刨析一份它官方的解析供各位阅读理解和使用,附原文链接:Gitflow官网、Gitflow论文。
什么是Gitflow
Giflow是另一种Git分支模型,它涉及特性分支和多个主分支的使用。它是由nvie的Vincent Driessen首次出版并流行起来的。基于主干的开发相比,Giflow拥有大量的、寿命更长的分支和更大的提交。在这个模型下,开发人员创建一个特性分支,并延迟将其合并到主干分支,直到特性完成。这些长期存在的特性分支需要更多的协作来合并,并且从主干分支偏离的风险更高。它们还会引入冲突的更新。
Gitflow可以用于有计划发布周期的项目,也可以用于持续交付的DevOps最佳实践。除了特性分支工作流所需要的,这个工作流没有添加任何新的概念或命令。相反,它为不同的分支分配非常具体的角色,并定义它们应该如何以及何时进行交互。除了特性分支之外,它还使用单独的分支来准备、维护和记录发布。当然,您还可以利用特性分支工作流的所有好处:拉请求、隔离实验和更高效的协作。
Gitflow流程讲解
gitflow分为以下几种分支,各个分支都有属于自己的流程定制,以下是描述分支的含义。
1.feature分支(功能分支、特性分支)
2.develop分支(活跃的分支、开发分支)
3.release分支(发布版本分支)
4.hotfixes分支(紧急版本分支、紧急修复分支)
5.master分支(主分支、核心分支)
feature分支
feature(特性分支) 也可以称为功能分支,它是从dev分支上衔生下来的分支,专注用于本地开发及本地测试(解释:feature属于本地分支,本地分支和远端分支是不同的,本地分支仅存在于本地git库中,当我们本地分支开发完成后再与远端的dev分支进行合并),并且该分支也是临时分支,当我们所涉及到的功能开发完成之后则将该分支合并到dev分支,例如:同事A负责订单模块,同事B负责库存模块,同事C负责物流信息模块,那么同事A、同事B、同事C它们将分别在dev分支上衔生出自己的分支,同事A(feature-订单XX功能)、同事B(feature-库存XX功能)、同事C(feature-物流XX功能),后续开发完成后只需要将各自的分支合并到dev分支即可,并且本地feature分支则可以删除,等开发下一个功能的时候则继续再dev分支上进行衔生feature分支。
develop分支
develop(开发分支) 也可以称为活跃分支,由master分支衔生出的分支,它与master分支都可以称为是整个项目的核心分支,所有的feature分支都是基于dev分支进行衔生的,当然dev分支也是属于比较活跃的分支,日常的测试版本都是基于dev分支进行构建发布的,所以dev分支的流动性很大很活跃,可以将dev分支比作为一个项目组,组员比作为feature,每次组员完成任务的时候都会上交到组内管理的地方,如果项目组比较大的话,也可以创建多个dev分支进行分开管理,比如项目组内有50人,那么可以选择每10人共用一个dev,只不过就要在基于dev之上进行创建一个dev总分支,用于将各个组的dev分支进行合并。
注意: 以下的黑色长线代表的是time(时间),我自己画的图只是便于让各位理解,真实的情况和我画的不符合。
release分支
release(版本分支) 也可以理解为上线分支,当我们有新的版本的时,将在远端最新的dev分支中衔生出一个版本分支用于发布版本,正常情况下: 成功发布版本一段时间后,将release分支合并到master分支上即可,但如果发布过程中遇到问题的话则修改当前的发布分支,修改完成后则发布版本,版本发布后稳定一段时间之后则将更改后的版本分支合并到master分支与dev分支上,确保稳定发版后master分支和dev分支保持一致,完成一系列操作后将release分支进行删除,建议: 如果担心版本不是太稳定的话,则可以将版本分支只合并到dev分支即可,万一后续生产出问题的话,也可以通过master分支衔生出一个版本分支进行修复,等到问题修复后确定不会再有其他问题后,再将master分支也进行合并。
hotfixes分支
hotfixes(紧急分支) 也可以理解为修复版本分支,release版本分支发布生产后的一段时间如果出问题了,则可以在合并过release分支的master分支或dev分支(如果提前预测生产会出问题的话有可能之前没有将release合并到master分支,而只是合并到了dev分支,所以只能在dev分支上衔生出一个修复分支,如果之前将release分支合并到了master,那么创建修复分支的时候就可以在master分支上衔生)上衔生出一个修复分支用于修复生产的BUG,等到问题修复后确定不会再有其他问题后,将master分支与dev分支进行合并,因为master分支和dev分支是核心分支,两个分支的内容尽可能的保持一致(发布生产后保持一致,如果是日常开发所创建的feature分支则无需频繁合并)。完成一系列操作后hotfixes分支进行删除。
master分支
master分支(核心分支,主分支): 图中的master分支代表的是main分支,master分支视为核心分支,其作用是确保项目的稳定运行,如果生产上出现致命且复杂的问题,而这个问题短时间又无法修复的话,则可以通过master分支衔生出一个版本分支进行修复。注意: 前提是master分支和dev分支相差一个小版本,否则的话即使通过master分支衔生了版本分支也是无济于事的,毕竟两个分支的内容都是一致。建议: master稳定分支千万不要频繁更新太快,否则的话生产出现致命且难修复问题,那就遭殃了~
Gitflow总结
1.dev-开发分支是从master分支派生的。
2.feature-特性分支是从dev-开发分支派生的,feature只是本地分支,不会被上传远端,特殊环境例外。
3.feature-特性分支完成时,它被合并到dev-开发分支中。
4.feature-特性分支合并完成后删除。
4.release-发布分支是从dev-开发分支派生的。
5.release-发布分支发布完成时,它被合并到master分支和dev-开发分支中(前提是保证版本的稳定性后再合并到master分支上)。
6.release-发布分支合并完成后删除。
7.版本出现问题时候则通过master分支派生出hotfixes-紧急分支进行修复,修复完成后将它合并到master分支和dev-开发分支中。
8.hotfixes-紧急分支合并完成后删除。
Gitflow客户端工具
下载地址:gitflow可视化工具-安装教程