声明

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

git管理-最详细Gitflow讲解相关推荐

海量数据大课学习笔记（6）-短链平台项目创建+git代码管理+开发分层规范讲解--小滴课堂
文章目录前言第1集短链平台实战-Maven聚合工程创建微服务项目第2集 Gitee仓库介绍和项目纳入版本管理+ignore文件配置第3集阿里编码规范里面Manager分层介绍-和开发规范说 ...
视频教程-零基础Redis详细案例讲解课程（第3季）---键管理、慢查询、管理命令-NoSQL
零基础Redis详细案例讲解课程(第3季)---键管理.慢查询.管理命令十年IT经验工作经验,现任系统架构师职务,自创易学笔记序列,擅长培养新人学习能力和学习思维,授人以鱼不如授人以渔.易学笔记全栈 ...
Spring 事务管理的详细讲解及使用
文章目录一. Spring 事务管理简介二.Spring 事务管理器 1.Spring 事务管理接口 1.1. PlatformTransactionManager 接口 1.2. Transac ...
git stash的详细讲解
应用举例通过几个实际的示例来了解一下git stash的强大. 开发到一半,同步远端代码当你的开发进行到一半,但是代码还不想进行提交 ,然后需要同步去关联远端代码时.如果你本地的代码和远端代码没有 ...
git管理和自动部署项目
当一个项目需要纳入到版本控制的时候,选择的工具还是比较多的,最常见的就是工具有CVS,SVN,GIT等.在平时的开发中视情况而定,从来就没有最好的版本控制工具,只有最适合的工具.在这里我习惯用git来 ...
Git管理工具对比（GitBash、EGit、SourceTree）(转载)
Git管理工具对比(GitBash.EGit.SourceTree) GitBash是采用命令行的方式对版本进行管理,功能最为灵活强大,但是由于需要手动输入希望修改的文件名,所以相对繁琐. EGit是 ...
《Puppet实战手册》——1.4　利用Git管理配置清单
本节书摘来自异步社区<Puppet实战手册>一书中的第1章,第1.4节,作者:[英]John Arundel著,更多章节内容可以访问云栖社区"异步社区"公众号查看 1. ...
Git教程_2 所有操作讲解
https://gitee.com/fakerlove/git 文章目录 2. 所有操作讲解 2.1 创建版本库 2.2 文件的基本操作 1. 创建 2. 添加 3. 提交 2.3 工作区和暂存区 2 ...
Git使用技巧--详细教程
Git使用流程及技巧 - 详细教程前言 1. 技巧 1.1. 基础技巧 1.2. 解决Git Bash命令行的中文乱码问题 1.2.1. 情况1:内部资源乱码 1.2.2. 情况2:远程库资源乱码( ...

git管理-最详细Gitflow讲解

GitFlow

声明