git管理-最详细Gitflow讲解

声明

   近期公司组内对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可视化工具-安装教程