git-flow流程规范

[TOC]

git flow是什么

GitFlow是构建在Git之上的一个组织软件开发活动的模型，被誉为是在Git之上构建的一项软件开发最佳实践。
它定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。
与feature branch workflow比起来，GitFlow没有增加任何新的概念和命令，它只是一个git管理的规范，一个开发的指导方针。

为什么要推动使用git flow

虽然有这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：

• 如何开始一个Feature的开发，而不影响别的Feature？
• 由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？哪些分支已经合并回了主干？
• 如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在PrepareRelease的时候，开发人员可以继续开发新的功能？
• 线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?
• 如何快速的找到每个上线的版本进行打包

大部分开发人员现在使用Git就只是用三个甚至两个分支，一个是Master, 一个是Develop, 还有一个是基于Develop打得各种分支。这个在小项目规模的时候还勉强可以支撑，因为很多人做项目就只有一个Release, 但是人员一多，或者项目周期一长就会出现各种问题。

接下来我们来介绍规范下的分支

gitFlow常用分支

主分支

• master分支

master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。
当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。
同时，每一次更新，最好添加对应的版本号标签（TAG）。
这个分支只能从其他分支合并，永远不要在这个分支直接修改

• develop分支

develop分支是保存当前最新开发成果的分支。
通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。
因此这个分支有时也可以被称作“integration branch”。
当develop分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。
对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。
因此，每次将develop分支上的代码合并回master分支时，我们都可以认为一个新的可供在生产环境中部署的版本就产生了。
通常而言，“​仅在发布新的可供部署的代码时才更新master分支上的代码​”是推荐所有人都遵守的行为准则。
基于此，理论上说，每当有代码提交到master分支时，我们可以使用Git Hook触发软件自动测试以及生产环境代码的自动更新工作。
这些自动化操作将有利于减少新代码发布之后的一些事务性工作。

辅助分支

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

• 用于开发新功能时所使用的feature分支；
• 用于辅助版本发布的release分支；
• 用于修正生产代码中的缺陷的hotfix分支。

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

• feature分支

使用规范：

• 可以从develop分支发起feature分支
• 代码必须合并回develop分支
• feature分支的命名可以使用除master，develop，release-/*，hotfix-/*之外的任何名称

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

• release分支

使用规范：

• 可以从develop分支派生
• 必须合并回develop分支和master分支
• 分支命名惯例：release-*,release/

release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。
成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。

• hotfix分支

使用规范：

• 可以从master分支派生

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

• 分支命名惯例：hotfix-*,hotfix/

  除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。 当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。 这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。 ### 更进一步

Git Flow开发模型从源代码管理角度对通常意义上的软件开发活动进行了约束。应该说，为我们的软件开发提供了一个可供参考的管理模型。Git Flow开发模型让nvie的开发代码仓库保持整洁，让小组各个成员之间的开发相互隔离，能够有效避免处于开发状态中的代码相互影响而导致的效率低下和混乱。

所谓模型，在不同的开发团队，不同的文化，不同的项目背景情况下都有可能需要进行适当的裁剪或扩充。

Practice

标准实践是完全按照gitflow工作流的规范进行操作，上面也提到过，规范只是一个指导方针，真正如何使用还需要结合自己项目和团队的风格进行改进，下面就是根据标准范式演化出来的一种工作流模式
如图所示，我们开发的过程中按照版本迭代开启一个新的release分支，这个分支将一直存在直到测试完成发布上线。但是其实并不在release上进行开发，而是在feature分支根据个人喜好进行开发，开发完成后再合并到release分支
而feature分支可以根据喜好分为按照功能创建，或者按照个人身份创建。如果一个功能比较大，或者说比较独立，可以单独开一个分支进行独立开发。而如果另外一个人主要进行小修小改（在版本迭代过程中应该会经常遇到修复上一个版本的小问题，或者UI微调整），那就可以一直在自己专属的分支进行开发工作。开发完成后再不断的合并到release分支上
无论哪种开发模式，都应该谨记一点，就是要坚持勤push代码，勤pull代码

可能大家会发现这种开发模式会造成develop分支多余，我也觉得develop这个分支有点鸡肋，暂时没发现可以做什么，不过还是保留吧，谁知道哪天又需要了。

Git flow工具

git-flow 是一个 git 扩展集，是完全按照标准GitFlow工作流程封装的一套git指令集合，用以帮助我们更方便的按照git-flow工作流程进行版本管理

安装

• OS X

brew install git-flow

• Linux

apt-get install git-flow

• Windows

wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

使用

• 初始化:git flow init
• 开始新Feature:git flow feature start MYFEATURE
• Publish一个Feature(也就是push到远程):git flow feature publish MYFEATURE
• 获取Publish的Feature:git flow feature pull origin MYFEATURE
• 完成一个Feature:git flow feature finish MYFEATURE
• 开始一个Release:git flow release start RELEASE [BASE]
• Publish一个Release:git flow release publish RELEASE
• 发布Release:git flow release finish RELEASE
  别忘了git push --tags
• 开始一个Hotfix:git flow hotfix start VERSION [BASENAME]
• 发布一个Hotfix:git flow hotfix finish VERSION