企业级开发：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虽然总是存在但却不常使用。

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

master 分支

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

develop分支

develop分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作整合分支（integration branch）。

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

辅助分支包括：

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

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

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

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

使用规范：

可以从develop分支发起feature分支

代码必须合并回develop分支

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

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

使用规范：

可以从develop分支派生

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

分支命名惯例：release-*

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

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

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

使用规范：

可以从master分支派生

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

分支命名惯例：hotfix-*

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

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

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

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

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

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

比如使用git stash就可以把暂存区 和 工作目录的修改保存起来，让暂存区 和 工作目录处于干净的状态。

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

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

Forking Workflow

Forking Workflow这种工作流主要好处就是每个开发者都拥有自己的远程仓库，可以将提交的commits推送到自己的远程仓库，但只有工程维护者才有权限push提交的commits到官方的仓库，其他开发者在没有授权的情况下不能push。Github很多开源项目都是采用Forking Workflow工作流。

Git版本控制与工作流

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