一、 Git Flow 工作模型的原理

无规矩不成方圆，但是规矩太多了，则感觉到束缚。我们一个人工作的时候喜欢无拘无束，想怎么干就怎么干，没有人评判，没有人检验。时间久了就会盲目自大，以为增删改查熟悉业务就能够搞定一些。但是当项目逐渐扩大，原来的灵活逐渐变成了混乱，原来的快速迭代因为过于随意的代码，而开发进度迟迟不前。掌握一种规范，便在处理类似问题的时候有章可循，也能够快速的融入一个团队。另外所谓规范，可以说是比较好的实践，按照规范来，项目也能稳健的发展。

Git Flow 就是如何使用git 分支的一种规范，或者叫做推荐。


(相关资料图)

根据Git Flow 的推荐，我们要将Git 的分支分为 master、develop、hotfix、release、feature这五个分支。各种分支分别负责不同的功能，平时开发的时候各司其职，因此会有比较小的冲突率。那么可以用这些减少冲突的时间，少加会班，多有点自己的生活岂不快哉。一图胜千言：

Git flow工作流程

master 分支

master 分支主要方稳定、随时可上线的版本。这个分支只能从别的分支上合并过来，一般来讲，从develop 上合并，或者从bugfix 分支上合并过来。不能直接在master 分支上进行commit文件。因为是稳定的版本，所以每次版本发布都要在这个分支上添加标签(tag)。

develop 分支

develop 分支是所有开发分支的母体，所有的开发分支都要从develop上切出来，开发完成之后最后都要合并到develop上。

hotfix 分支

hotfix 分支用来修复生产中的紧急bug，由于develop分支尚处于开发过程中，代码不稳定，不能直接应用于生产。所以从master分支上切出一个分支，修复完成之后合并到master分支，并且合并到develop上。

release 分支

release 分支可以称之为预发布的版本。当我们认为develop版本的代码已经趋于成熟，我们可以打一个release分支。在release 分支上测试完成之后，要将代码合并到master分支和develop上。master 分支是线上版本，而合并到develop版本是因为，在测试过程中，一些细节的东西可能会修改，因此这些优化的内容也应该合并到最终版本以及开发版本中。

feature 分支

feature 分支是最经常使用的分支了。当我们收到一个新的开发功能时，应该在develop分支上切出一个feature分支。用来完成新功能的开发，开发完成之后，要合并进develop分支上。

二、 Git Flow 工具的使用

基本上各种git的客户端软件都会支持Git Flow 工作模型。sourcetree 上使用git flow 工作模型就很流畅，体验很好。但是为了全平台上通用，以及理解原理，快速上手。我们来学习下Git Flow 的命令行操作。

git flow 是一种git的使用规范，当然也有相应的工具集，命令行命令让我们使用。

1、起步

安装git flow

brew install git-flow-avh

初始化git flow 工具库

git flow init之后都按照默认的去配置，直接按enter键继续。

2、feature 分支操作

增加feature新特性分支

适用场景，需要开发新功能

git flow feature start your roverliang/addlist

示例:

roverliang$ git flow feature start roverliang/addlistSwitched to a new branch "feature/roverliang/addlist"Summary of actions:- A new branch "feature/roverliang/addlist" was created, based on "develop"- You are now on branch "feature/roverliang/addlist"Now, start committing on your feature. When done, use:     git flow feature finish roverliang/addlistroverliang$ git branch  develop* feature/roverliang/addlist  master

完成新特性这个动作执行的是下面的流程:

合并 addlist 分支到 develop删除这个新特性分支切换回 develop 分支
git flow feature finish roverliang/addlist

示例：

roverliang$ git flow feature finish roverliang/addlistSwitched to branch "develop"Your branch is up to date with "origin/develop".Already up to date.Deleted branch feature/roverliang/addlist (was 2e1b475).Summary of actions:- The feature branch "feature/roverliang/addlist" was merged into "develop"- Feature branch "feature/roverliang/addlist" has been locally deleted- You are now on branch "develop"roverliang$ git branch* develop  masterroverliang$

获取一个发布的新特性的分支

git flow feature track origin MYFEATURE

3、release 分支操作

准备release 版本

git flow release start RELEASE [BASE]你可以选择提供一个 [BASE]参数，即提交记录的 sha-1 hash 值，来开启动 release 分支. 这个提交记录的 sha-1 hash 值必须是"develop" 分支下的。

示例：

roverliang$ git branch  develop  feature/test* masterroverliang$ git log --pretty=oneline -32e1b475f9825275aefa0892cfe5259aaac9a3483 (HEAD -> master, origin/test2, origin/master, origin/feature/test, origin/develop, feature/test, develop) delte some content2d22f306d2dca363b8aaa05743be342a505aabb0        renamed:    demo.txt -> test.txtfbf025e210952c3cdb10e219c4ee5f82b9f36327        modified:   demo.txtroverliang$

发布release 版本

git flow release track RELEASE

完成release 版本

相当于执行以下几个动作：

归并 release 分支到 "master" 分支用 release 分支名打 Tag归并 release 分支到 "develop"移除 release 分支
git flow release finish RELEASE

4、bugfix 分支操作

紧急修复的需求：

紧急修复来自这样的需求：生产环境的版本处于一个不预期状态，需要立即修正。有可能是需要修正 master 分支上某个 TAG 标记的生产版本。

开始紧急修复，开启hotfix 分支

git flow hotfix start VERSION [BASENAME]VERSION 参数标记着修正版本。你可以从 [BASENAME]开始，[BASENAME]为finish release时填写的版本号

完成紧急修复

当完成紧急修复分支，代码归并回 develop 和 master 分支。相应地，master 分支打上修正版本的 TAG。

git flow hotfix finish VERSION

关键词：