企业级开发：Gitflow Workflow工做流

我说的如下流程，sourceTree等工具已经完美的支持了，鼠标点两下就完成了。简直是完美。

简介

Feature Branch Workflow是一种很是灵活的开发方式。对于一些规模比较大的团队，最好就是给特定的分支赋予不一样的角色。除了功能分支(feature branch)，Gitflow Workflow还使用独立的分支来准备发布(preparing)，维护(maintaining), 和记录版本(recording releases)。

分支类型和流程

下图能说明整个流程，只要你看得懂的话。该模式来自 Nvie

• feature（多个、玫红）。主要是本身玩了，差很少的时候要合并回develop去。从不与master交互。

• develop（1个、黄色）。主要是和feature以及release交互。

• release（同一时间1个、绿色）。老是基于develop，最后又合并回develop。固然对应的tag跑到master这边去了。生命周期很短，只是为了发布

• hotfix（同一时间1个、红色）。老是基于master，并最后合并到master和develop。生命周期较短，用了修复bug或小粒度修改发布。

• master（1个蓝色）。没有什么东西，仅是一些关联的tag，因从不在master上开发。

在这个模型中，master和develop都具备象征意义。master分支上的代码老是稳定的（stable build），随时能够发布出去。develop上的代码老是从feature上合并过来的，能够进行Nightly Builds，但不直接在develop上进行开发。当develop上的feature足够多以致于能够进行新版本的发布时，能够建立release分支。

release分支基于develop，进行很简单的修改后就被合并到master，并打上tag，表示能够发布了。紧接着release将被合并到develop；此时develop可能往前跑了一段，出现合并冲突，须要手工解决冲突后再次合并。这步完成后就删除release分支。

当从已发布版本中发现bug要修复时，就应用到hotfix分支了。hotfix基于master分支，完成bug修复或紧急修改后，要merge回master，打上一个新的tag，并merge回develop，删除hotfix分支。

因而可知release和hotfix的生命周期都较短，master/develop虽然老是存在但却不常使用。

分支详解

主分支 （Historical Branches）

主分支是全部开发活动的核心分支。全部的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和development分支。

master 分支

master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签（TAG）。

develop分支

develop分支是保存当前最新开发成果的分支。一般这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。所以这个分支有时也能够被称做整合分支（integration branch）。

辅助分支

辅助分支是用于组织解决特定问题的各类软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工做以及对生产代码的缺陷进行紧急修复工做。这些分支与主分支不一样，一般只会在有限的时间范围内存在。

辅助分支包括：

1. 用于开发新功能时所使用的feature分支；

2. 用于辅助版本发布的release分支；

3. 用于修正生产代码中的缺陷的hotfix分支。

以上这些分支都有固定的使用目的和分支操做限制。从单纯技术的角度说，这些分支与Git其余分支并无什么区别，但经过命名，咱们定义了使用这些分支的方法。

feature 分支

使用规范：

1. 能够从develop分支发起feature分支

2. 代码必须合并回develop分支

3. feature分支的命名可使用除master，develop，release-*，hotfix-*以外的任何名称

feature分支（有时也能够被叫作“topic分支”）一般是在开发一项新的软件功能的时候使用，这个分支上的代码变动最终合并回develop分支或者干脆被抛弃掉（例如实验性且效果很差的代码变动）。

release分支（preparing）

使用规范：

• 能够从develop分支派生

• 必须合并回develop分支和master分支

• 分支命名惯例：release-*

release分支是为发布新的产品版本而设计的。在这个分支上的代码容许作小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。经过在release分支上进行这些工做可让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。

当develop分支上的代码已经包含了全部即将发布的版本中所计划包含的软件功能，而且已经过全部测试时，咱们就能够考虑准备建立release分支了。而全部在当前即将发布的版本以外的业务需求必定要确保不能混到release分支以内（避免由此引入一些不可控的系统缺陷）。

成功的派生了release分支，并被赋予版本号以后，develop分支就能够为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本以后发布的版本。版本号的命名能够依据项目定义的版本号命名规则进行。

hotfix分支（maintaining）

使用规范：

• 能够从master分支派生

• 必须合并回master分支和develop分支

• 分支命名惯例：hotfix-*

除了是计划外建立的之外，hotfix分支与release分支十分类似：均可以产生一个新的可供在生产环境部署的软件版本。

当生产环境中的软件遇到了异常状况或者发现了严重到必须当即修复的软件缺陷的时候，就须要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工做。

这样作的显而易见的好处是不会打断正在进行的develop分支的开发工做，可以让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工做。

问题

管理冲突

1. 多个Feature 分支开发完成，提交到develop 分支时，修改了共同的模块。

2. release 分支或者hotfix 分支修改了bug合并回develop时，发现develop分支已经往前面走了一截。

在执行可能有冲突的操做前，先查看一下 暂存区 和 工做目录，保证其中没有修改。

好比使用git stash就能够把暂存区 和 工做目录的修改保存起来，让暂存区 和 工做目录处于干净的状态。

更进一步

Gitflow workflow 和pull request 组合起来使用，代码审查机制的加入，会让这个模式大放异彩。下一篇文章中， 我会详细介绍 代码审查????。

扩展：Forking Workflow

Forking Workflow与以上讨论的工做流很不一样，一个很重要的区别就是它不仅是多个开发共享一个远程仓库(central repository)，而是每一个开发者都拥有一个独立的服务端仓库。也就是说每一个contributor都有两个仓库：本地私有的仓库和远程共享的仓库。

Forking Workflow

Forking Workflow这种工做流主要好处就是每一个开发者都拥有本身的远程仓库，能够将提交的commits推送到本身的远程仓库，但只有工程维护者才有权限push提交的commits到官方的仓库，其余开发者在没有受权的状况下不能push。Github不少开源项目都是采用Forking Workflow工做流。

文章来源

Git版本控制与工做流

基于git的源代码管理模型——git flow