git flow是git的辅助工具，实质上是一些分支-合并的脚本集合，使用git flow可以更轻松的完成对各种特性分支的操作。

安装

apt-get install git-flow
将git库转换为git-flow库

git flow init
开始一个新功能

git flow feature start xxxx
提交这个功能到远程库

git flow feature publish xxxx
完成功能，合并到develop

git flow feature finish xxxx
记得删除远程仓库里的分支

git push origin :xxxx
release,hotfix与之类似，唯一的一点区别：hotfix目前没有publish功能，所以提交远程仓库的这一步要改成：

git push origin hotfix/xxxx:hotfix/xxxx
注意

git flow只是在本地执行分支/合并操作的脚本，不是一个流程管理工具。

GitFlow 工作流


GitFlow是什么？

GitFlow是一套基于git的工作流程，这个工作流程围绕着项目发布定义了一个严格的如何建立分支的模型。
GitFlow规定了如何建立、合并分支，如何发布，如何维护历史版本等工作流程。简单说就是每一个功能特性的开发是在分支上开发，而不是在主干开发，分支开发完毕后再合并到主干上。



GitFlow的优势

还处于半成品状态的feature不会影响到主干
各个开发人员之间做自己的分支，互不干扰
主干永远处于可编译、可运行的状态



GitFlow分支简述



主干分支（master和develop）

master分支存储了发布版本的历史，各个版本通tag来标记（git tag -a v0.1）
develop分支是一个集成分支，用来整合各个功能feature分支，也方便给master分支上的所有提交分配一个版本号。


功能分支（feature）

开发每个新功能都必须新开个feature分支，feature分支派生自develop分支。
开发完成后要合并回develop分支。feature分支永远不会和master分支打交道。


待发布分支(release)

release分支不是一个放正式发布产品的分支，可以理解为预发布或者待发布分支。
当开发的功能完成并满足发布的条件时，将这些满足条件的feature分支合并到develop分支上，然后从develop分支开出一个release分支，开始准备一个发布版本。
在release分支上，不能再添加新的功能，但是我们可以:

将分支打包给测试人员测试
在这个分支上修改bug
编写发布文档
当到发布日时，发布相关的工作都完成后，release分支合并回master分支，并打出版本标签，发布完成后，release分支合还要并回develop分支。




维护分支(hotfix)

维护分支也就是bug修复分支，用来快速修复生产环境的紧急问题。
项目发布后或多或少会有一些bug存在，而bug的修复工作并不适合在develop上做，这是因为:

develop分支上可能包含还未验证过的feature
用户未必需要develop上的feature
develop还不能马上发布，而客户急需这个bug的修复。


这个分支是唯一一个开放过程中直接从master分支派生来的分支。

快速的修复问题后，hotfix分支应该被合并回master分支，同时也要合并回develop分支，这样develop分支也能享受到bug修复的好处。然后master分支需要打一个版本标签，例如v0.11。




4.GitFlow的命名约定




分支
命名




主分支
master


主开发分支
develop


标签（tag）
v##，如：v1.0.0


新功能开发分支
feature-games或feature/gamesp


发布分支名
release-1.0.0或release/1.0.0


维护分支
hotfix-update或hotfix/update


参考文档

Git



Git工具

版本控制工具，管理代码，方便追溯和协作开发。

安装：



brew intall git
git config --global user.name 'Git用户名'
git config --global user.email '账号邮箱'

克隆项目：



git clone 地址

基本使用：



git add xxx
git commit -m 'xxx'

查看状态和日志：



git status
git log

管理分支：



git checkout -b 新分支
git branch 查看分支
git chekcout 切换分支名次

远程分支：



git remote add 名称 地址
git remote -v
git fetch
git pull
git push

分支合并：



git merge
git rebase



GitFlow

Git Flow是基于GIT的开发流程规范，能够通过创建有分别的分支进行管理开发，有效的进行开发合作的工具。



分支概述

这里结合下图，对博文内容中的分支做一个概述性的说明：



如图所示,一个项目需要被分成master、develop、feature、release、hotfix五个分支。 

根据类别可以分为主要分支和辅助分支两个类别：

主要分支：master、develop
辅助分支：feature、release、hotfix
主要分支



主分支（master）

master是git创建项目后默认在orign中的，他的头(HEAD)永远是produciton-ready的状态。也是当每个项目发布的最终版本的分支。



开发分支（develop）

develop分支是所有代码头是记录下一个发布版本的最新更新的分支。 

当develop分支的代码已经可以被发布的时候，他将会被合并到主分支上并打上发布标签。



辅助分支

辅助分支是帮助团队成员进行协同开发使用的，它可以比较容易追踪特性，准备产品发布且快速修复产品中的问题，每个辅助分支有着不同的作用和界限。



特性分支（feature branches）

特性分支是用来开发下一个版本的新特性使用的分支，他在开发完成后合并到开发分支中。也就是说一般开发新功能都是要创建这个分支。

一般来说特性分支遵从下面规范：

来源如无特别情况是develop；
必须合并到develop上；
命名规则除了master、develop、release/、hotfix/ 以外的命名。
发布分支（release branches）

发布分支是为产品发布做准备的分支,他可以修复小的bug且准备发布元信息（版本号码、创建日期等）。也就是发布到master前的最后一步准备。

一般来说发布分支遵从下面规范：

来源如无特别情况是develop；
必须合并到develop和master上；
命名规则为release/*的形式。
修复分支（hotfix branches）

修复分支主要是突发情况下对发布产品进行版本BUG修复的分支。如果遇到重大BUG，需要立即创建分支进行修复合并。

一般来说修复分支遵从下面规范：

来源如无特别情况是master；
必须合并到develop和master上；
命名规则为hotfix/*的形式。
注：辅助分支都在自己的本地分支进行开发。



Github

项目组织上利用Github或者Gitlab中milestone、label及issue来组织整个项目。



开发组织元素



版本号

Whiterun的版本号用三位的命名，例如“v1.1.1”，其中：

前两位数为主版本号及发布的版本；
最后一位数为内部开发的版本，在为milestone组织提供依据。
Label

目前根据需求分为五种Label，之后可能会根据需求进行修改：

分支合并：当合并到develop分支时，进行添加；
功能改进：当开发需求在原先基础上的拓展，进行添加；
版本发布：只有当develop合并到master进行发布时添加；
特性添加：当开发需求是添加新的功能时，进行添加；
bug修复：当开发需求是修复原先的Bug时，进行添加。
开发流程

当收集了一定的需求后，建立milestone，以版本来命名milestone，说明里写入主要内容，并确立开发截至时间，通常一周；
根据需求建立各自的issue，issue命名根据需求是技术、业务以及bug等在开头用[]来注明，issue里需要写出具体的需求内容以及检查点，为issue设立label、对应的milestone以及开发者；
根据情况构建特性(features)、hotfixes等分支进行开发，提交的代码需要进行测试且构建其文档，提交commit里以Fix #issue号: 提交内容的格式书写；
PR的合并需要基于develop分支，合并的代码需要进行CodeReview，完成后可以进行合并；
完成每个milestone后，将develop合并到master上，在PR内容里写上本次迭代的全部issue内容号，完成迭代。
PR



检查列表

对每个issue，提交的PR需要添加CheckList来说明PR中的点，最好勾选其中的完成项目，保证PR的考虑完整。

PR CheckList模版如下：



描述: xxxxxx

检查项:
- [ ] 修改models层
 - [ ] 修改查询语句
 - [ ] 创建新表
  - [ ] 已提交建表SQL到DBA审核
  - [ ] 已提交查询和写入SQL到DBA审核
  - [ ] 已评估读写频次

- [ ] 新增/修改业务逻辑
 - [ ] 已通知受影响方
  - [ ] 业务方1
  - [ ] 业务方2
 - [ ] 新增/变更的功能点列表
  - [ ] 功能点1
   - [ ] 已测试
  - [ ] 功能点2
   - [ ] 已测试

- [ ] 上线方案
 - [ ] 确定预期上线时间
 - [ ] 上线时间已通知运维
 - [ ] 是否特别需要监控
  - [ ] 已通知监控
 - [ ] 是否需要添加新配置项
  - [ ] 已通知运维



Code Review

当提出PR后，需要让其他开发成员进行CodeReview，如果没有问题后，合并到Develop分支上。

备注：  

转载请注明出处：http://blog.csdn.net/wsyw126/article/details/55001367 

作者：WSYW126

安装
curl -L -O https://raw.github.com/nvie/gitflow/develop/contrib/gitflow-installer.sh

sudo bash gitflow-installer.sh