Git Flow 工做模型与使用

1、 Git Flow 工做模型的原理

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

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

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

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分支上。

2、 Git Flow 工具的使用

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

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

一、起步

安装git flow

brew install git-flow-avh

初始化git flow 工具库

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

二、feature 分支操做

增长feature新特性分支

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

git flow feature start your roverliang/addlist

示例:

roverliang$ git flow feature start roverliang/addlist
Switched 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/addlist

roverliang$ git branch
  develop
* feature/roverliang/addlist
  master

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

• ☆ 合并 addlist 分支到 develop
• ☆ 删除这个新特性分支
• ☆ 切换回 develop 分支

git flow feature finish roverliang/addlist

示例：

roverliang$ git flow feature finish roverliang/addlist
Switched 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
  master
roverliang$

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

git flow feature track origin MYFEATURE

三、release 分支操做

准备release 版本

git flow release start RELEASE [BASE]

你能够选择提供一个 [BASE]参数，即提交记录的 sha-1 hash 值，来开启动 release 分支. 这个提交记录的 sha-1 hash 值必须是'develop' 分支下的。

示例：

roverliang$ git branch
  develop
  feature/test
* master
roverliang$ git log --pretty=oneline -3
2e1b475f9825275aefa0892cfe5259aaac9a3483 (HEAD -> master, origin/test2, origin/master, origin/feature/test, origin/develop, feature/test, develop) delte some content
2d22f306d2dca363b8aaa05743be342a505aabb0        renamed:    demo.txt -> test.txt
fbf025e210952c3cdb10e219c4ee5f82b9f36327        modified:   demo.txt
roverliang$

发布release 版本

git flow release track RELEASE

完成release 版本

至关于执行如下几个动做：

• ☆ 归并 release 分支到 'master' 分支
• ☆ 用 release 分支名打 Tag
• ☆ 归并 release 分支到 'develop'
• ☆ 移除 release 分支

git flow release finish RELEASE

三、bugfix 分支操做

紧急修复的需求：

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

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

git flow hotfix start VERSION [BASENAME]

VERSION 参数标记着修正版本。你能够从 [BASENAME]开始，[BASENAME]为finish release时填写的版本号

完成紧急修复

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

git flow hotfix finish VERSION

本文参考：

• git-flow 备忘清单
• Git Flow 是什麼？為什麼须要這種東西？