git flow与分支管理

git flow与分支管理

一、git flow是什么

Git 作为一个源码管理系统，不可避免涉及到多人协作。

协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。“工作流程"在英语里，叫做"workflow"或者"flow”，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。

最早诞生、并得到广泛采用的一种工作流程，就是 Git flow 。

首先，项目存在两个长期分支。

• 主分支master
• 开发分支develop

前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。

其次，项目存在三种短期分支。

• 功能分支（feature branch）
• 补丁分支（hotfix branch）
• 预发分支（release branch）

一旦完成开发，它们就会被合并进develop或master，然后被删除。

二、分支管理

Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用。但是，太方便了也会产生副作用。如果你不加注意，很可能会留下一个枝节蔓生、四处开放的版本库，到处都是分支，完全看不出主干发展的脉络。

Vincent Driessen提出了一个分支管理的策略，非常值得借鉴。它可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。理论上，这些策略对所有的版本管理系统都适用，下文中Git只是用来举例而已，如果你不熟悉Git，跳过举例部分即可。

1、主分支Master

首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

2、开发分支Develop

主分支只用来发布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。

这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就需要切换到Master分支上对Develop分支进行"合并"（merge）。

// Git创建Develop分支的命令：
git checkout -b develop master

// 将Develop分支发布到Master分支的命令
# 切换到Master分支　　
git checkout master

# 对Develop分支进行合并　　
git merge --no-ff develop

这里稍微解释一下，上一条命令的–no-ff参数是什么意思。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。
fast-farward merge–no-ff
使用–no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考Benjamin Sandofsky的《Understanding the Git Workflow》。

3、临时性分支

前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。

但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：

• 功能（feature）分支
• 预发布（release）分支
• 修补bug（fixbug）分支

这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。

功能分支

第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

功能分支的名字，可以采用feature-*的形式命名。

// 创建一个功能分支：
git checkout -b feature-x develop

// 开发完成后，将功能分支合并到develop分支：
git checkout develop
git merge --no-ff feature-x

// 删除feature分支：
git branch -d feature-x

预发布分支

第二种是预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。

预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。

// 创建一个预发布分支：
git checkout -b release-1.2 develop

// 确认没有问题后，合并到master分支：
git checkout master
git merge --no-ff release-1.2

// 对合并生成的新节点，做一个标签　　
git tag -a 1.2

// 再合并到develop分支：
git checkout develop
git merge --no-ff release-1.2

// 最后，删除预发布分支：
git branch -d release-1.2

修补bug分支

最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。

修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。

// 创建一个修补bug分支：
git checkout -b fixbug-0.1 master

// 修补结束后，合并到master分支：
git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1

// 再合并到develop分支：
git checkout develop
git merge --no-ff fixbug-0.1

// 最后，删除"修补bug分支"：
git branch -d fixbug-0.1

三、分支管理最佳实践

1、分支名义规划

分支/tag名命名规则描述master分支
主分支master，固定不变永远是可用的、稳定的、可直接发布的版本，不能直接在该分支上开发。
用于迁移feature和hotfix分支，也用于打上线快照r_tag，用于上线feature-xxx
功能开发分支feature-{name}，以开发功能模块命名
不能有大写字母，多个单词之间用下划线替代由RD从master分支迁出，开发完成后合并到dev分支，提测的时候合并到qa分支，上线集成的时候需要合并到release分支。用于新需求或功能的开发也用于dev环境泳道的部署（非主干泳道的部署，主干泳道只能用master部署）qa
测试主分支qa，固定不变提测分支，qa分支只能由feature做merge合并，不能直接在该分支上开发，用于QA测试release-xxx
发布分支release-${yyyyMMdd}，以yyyyMMdd格式命名，如果一天有多个分支后面增加24单位的双位小时时间yyMMddHHrelease分支是测试完成后，由RD或QA创建，从master迁，并将feature分支merge到release分支。主要是用在预发环境集成测试。release-xxx-bug
功能bug修复分支release-${yyyyMMdd}-bug，参考release-xx分支的命名在release上创建分支修复，修复好提测的bug之后合并回release分支hotfix-xxx
紧急bug修改分支hotfix-{name}，以修复bug的名称命名。不能有大写字母，多个单词之间用下划线替代项目上线之后可能会遇到一些环境问题需要紧急修复，流程跟release分支相似，修复完成要上线的时候合并master分支b-tag TAGb-{yyyyMMdd}-{name}，不能有大写字母，多个单词之间用下划线替代b-tag从release分支打出，用于灰度上线验证r-tag TAGr-{yyyyMMdd}-{name}，不能有大写字母，多个单词之间用下划线替代r-tag用于上线的tag，由QA同学创建。灰度上线验证通过，会将release合并到master分支，从master打出r-taghotfix分支hotfix/{yyyyMMdd}-{bug}，不能有大写字母，多个单词之间用下划线替代用于线上bug的修复，从master分支迁出

2、环境与分支

固定代码分支与服务部署环境的关联关系如下表所示。
环境代码分支tag备注prodmasterrtag生产环境，即线上服务，上线应使用从master分支打出的r_tag上线stagingreleasebtagstaging环境，用master代码分支和配置进行验证，上线前的最后检查testqa无测试环境，用于支持QA同事做功能测试，部署权限需联系接口QA。devfeature无开发环境，用于研发同事之间做接口联调、功能测试。

3、分支图

四、git flow缺点

Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。

更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。但是，很多网站项目是"持续发布"，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。

分支太多，所以会出现 git log 混乱的局面。具体来说，主要是 git-flow 使用git merge --no-ff来合并分支，在 git-flow 这样多个分支的环境下会让你的分支管理的 log 变得很难看。如下所示，左边是使用–no-ff 参数在多个分支下的问题。

所谓–no-ff参数的意思是——no fast forward的意思。也就是说，合并的方法不要把这个分支的提交以前置合并的方式，而是留下一个 merge 的提交。这是把双刃剑，我们希望我们的–no-ff能像右边那样，而不是像左边那样。对此的建议是：只有 feature 合并到 developer 分支时，使用–no-ff 参数，其他的合并都不使用–no-ff参数来做合并。另外，还有一个问题就是，在开发得足够快的时候，你会觉得同时维护 Master 和 Developer 两个分支是一件很无聊的事，因为这两个分支在大多数情况下都是一样的。包括 Release 分支，你会觉得创建的这些分支太无聊。而你的整个开发过程也会因为这么复杂的管理变得非常复杂。尤其当你想回滚某些人的提交时，你就会发现这事似乎有点儿不好干了。而且在工作过程中，你会来来回回地切换工作的分支，有时候一不小心没有切换，就提交到了不正确的分支上，你还要回滚和重新提交，等等。

Git Flow 抛弃了 rebase如果你要使用 Git Flow，就得放弃 rebase。rebase 取消了合并提交——也就是可以看到两个分支合并的地方。由于 Git Flow 的复杂性，你需要可视化跟踪分支，这意味着如果你想要看到来龙去脉，就不能使用 rebase。