测试角度解读gitflow流程，为何需要分支开发

一、前言

1、什么是git

Git是一个分布式的版本管理工具，它分为远程仓库（云端仓库，存在后端服务器中）（仓库：repository简写repo：）和本地仓库。本地和云端的仓库的维护机制是类似的，它们都是使用一个类似一个树形结构的数据结构来维护的。

2、git的优点

git 是分布式的，有本地分支管理功能，所以，就算没有网络也可以进行本地的维护。
git的每个变动都是一个节点因此，每次的文件内容的变动都可以单独保存并且可以逐个的进行应用管理。在所有代码合并后也可以看到所有变更内容，而其他的版本管理工具则不可以。
由于git每次的变更都会生成一个完整的文件快照，所以它非常快。用空间来换取时间。
由于git会面临内存问题，它有自己的内存维护机制比如：删掉无用的节点，压缩打包历史记录等…
git有非常多的命令，可以灵活的使用。

二、什么是gitflow

1、GitFlow 协同工作流

    GitFlow并非什么技术，而是一种代码开发合并管理流程的思维模式或者是管理方法。大家一起开发的一种软约定。

    所有的功能开发与修改都在 master 分支上进行的。开发者开始先克隆中央仓库。在自己的项目拷贝中像SVN一样的编辑文件和提交修改；但修改是存在本地的，和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。

2、GitFlow的由来

我们为什么需要GitFlow这种git管理流程？原因有以下几点
1.有一个稳定版本的代码分支，可以安心的用在线上发布。
2.在代码提测前或者说是代码达到预发状态时，在测试交付的过程中程序员们还可以继续进行下一个版本的开发工作（挤出每一秒去开发）。
3.有个一个分支可以让我们及时的对线上的bug进行修复，这个过程中我们不希望将正在开发中的代码提交到线上生产中去。

由于上述开发过程中面临的需求，GitFlow协同国祚流应运而生。对应的点就是
1.代码共享
2.不同环境下代码互不干扰
3.管理好代码与环境的一致性

3、为何需要了解gitflow流程

项目角度：为了规避修改bug，需求开发带来的代码污染，更容易追溯问题，定位问题。
测试角度：掌握熟悉流程可以更好的帮助我们实现流程把控与风险预估，在不同的时间节点，可以很清晰的认知为何需要做这件事。

三、gitflow分支含义

1、Master 分支：

最为稳定功能比较完整的随时可发布的代码，即代码开发完成，经过测试，没有明显的bug，才能合并到 master 中。请注意永远不要在 master 分支上直接开发和提交代码，以确保 master 上的代码一直可用；

2、Feture 分支：

这个分支主要是用来开发新的功能，一旦开发完成，通过测试没问题（这个测试，测试新功能没问题），我们合并回develop 分支进入下一个 release 。

3、Developer 分支:

用作平时开发的主分支，并一直存在，永远是功能最新最全的分支，包含所有要发布 到下一个 release 的代码，主要用于合并其他分支，比如 feature 分支； 如果修改代码，新建 feature 分支修改完再合并到 develop 分支。所有的 feature、release 分支都是从 develop 分支上拉的。

4、Release 分支：

用于发布准备的专门分支。当开发进行到一定程度，或者说快到了既定的发布日，可以发布时，建立一个 release 分支并指定版本号(可以在 finish 的时候添加)。开发人员可以对 release 分支上的代码进行集中测试和修改bug。（这个测试，测试新功能与已有的功能是否有冲突，兼容性）全部完成经过测试没有问题后，将 release 分支上的代码合并到 master 分支和 develop 分支。

5、Hotfix 分支：

线上bug修缮用的分支，每次修改线上代码的bug时都要用hotfix来维护，从 master 分支上拉，完成后向Developer和Master同时合并。完成后删除分支。

6、注意事项

所有开发分支从 develop 分支拉。
所有 hotfix 分支从 master 拉。
所有在 master 上的提交都必要要有 tag，方便回滚。
只要有合并到 master 分支的操作，都需要和 develop 分支合并下，保证同步。
master 和 develop 分支是主要分支，主要分支每种类型只能有一个，派生分支每个类型可以同时存 在多个。

四、gitflow的工作方式

1、初始化分支

默认会初始化 master develop 两个主干分支。如果已有了不同分支，初始化的时候，可能需要手动指定 master 分支 跟 develop 分支。

2、开发分支feature

分支的名称都是以 feature/*-20170323 打头，不需要做修改
基于develop分支，可以有多个特征分支进行开发
feature分支做完后，必须合并回develop 分支，合并完分支后一般会删除这个 feature 分支（也就是 finish 一般由测试进行，或者经过测试允许），也可以视情况保留

3、发布分支release

分支名称以 release/*-20170323 打头
release分支基于develop创建； 一旦创建了release分支，不能在从 develop 分支合并新的改动到 release 分支,可以基于release分支进行测试和bug修改，测试不用在另外创建用于测试的分支。
release 发布的时候，合并到 master 和 develop 分支，同时打tag，视情况删除release分支，通常应该删除掉

4、维护分支hotfix

分支名称以 hotfix/* 开头
hotfix 分支基于 master 分支创建，开发完毕后合并到 master 和 develop 分支，同时创建 tag
这是唯一可以直接从 master 分支 fork出来的分支。

五、版本节奏流程图

1、理想流程图

2、灰度与内测

内测与灰度实际目的为一致的，通过部分用户先升级app版本运用，面向部分用户新功能体验，体验用户体验过程中收集异常crash等信息进行崩溃率监控。
目的：防止新需求或改动点造成某些功能出现crash，防止全量后大范围影响线上用户体验。

3、什么是灰度

灰度为server通过计算，对小部分用户给予app升级版本内测通道的给予，命中灰度实验的用户会在app内弹出升级版本弹窗。
对比QQ群内侧，灰度可以扩大内侧范围，小范围的内侧无法统计更多的崩溃问题，扩大内侧范围可以降低app的crash率。

4、灰度流程

如按流程图内进行，在周四回归测试结束后，需要对线上用户进行灰度发版，灰度1一般为小范围用户升级，一般占比约为10%。
发布灰度1时也是流量爬坡阶梯形式进行灰度1全亮，在灰度过程中，如果crash率高于预警，需要紧急停止灰度，修复后继续灰度发版。
灰度2一般比灰度1高，大约30%，继续扩大内侧范围，如果crash率高于预警也需停止灰度发版。
灰度对比为横向对比，需对比上一版本的crash率，如果明显高于上个版本，需排查问题。
灰度对比结束后，可以开始进行双端的阶梯全量发版。

六、不同节点注意事项

1、集成结束时间

多部门合作的情况下，对于集成结束的时间节点需要有明确的固定周期的日期，精确到整点分秒，在无特殊情况下（如：必须修复问题与需求造成集成时间延期和节假日原因导致集成时间需提前）必须严格遵循集成时间节点，这里不是为了卡流程而设计，而是为了增加流程的茁壮性，因为如果大家不严格遵循，大家都延期几十分钟或几个小时，会导致集成/集成回归/发版节奏混乱。

2、集成延期

如果出现集成延期，我们需要对导致延期的问题进行复盘，为什么延期，是因为最后测试临时发现问题导致，还是合并分支代码冲突导致，还是需求排期不合理导致，分析问题后后续需对延期问题总结进行优化。

比如：

     临时集成是测试发现问题：为什么最后的时间节点发现的问题，是测试排期紧张，还是测试颗粒度不够，后续如何规避提前发现问题，如果发现问题此需求是否有必要一定要赶当前版本，是否可以进入下一个版本迭代从而降低集成风险。

     合并分支代码冲突问题：在进行大需求开发的过程中，研发是否定期（如：一天的时间单位）的rebase 主分支develop的代码，保证需求分支的基础代码为较新状态，从而减少分支代码落后主分支develop过多导致集成冲突，解决冲突时间到集成延期风险。其次需求是否可以在集成结束时间节点提前半天集成，此方式可以规避两个需求分支对一个功能关联导致集成时发现冲突。

     需求排期不合理问题：从开发到测试的排期结束节点预估无法赶上当前发版时间节点，通过压缩需求进度时间赶发版进度，通过对比需求优先级，在前期及时调整人力完解决排期问题，规避因排期导致需求无法赶上集成发版节点。

3、集成回归

集成后回归测试时，应尽量使用release分支包进行回归测试，虽然release相对于devleop缺少很多测试配置功能，但是release是除了渠道包以外最接近线上用户的真实安装包。

如各方面条件允许的情况下（这里指的是测试需关注abtest，功能开关，框架调整等需要app内部切换内容），建议android采用渠道包进行回测测试，ios采用testflight内侧包进行回测测试，这两种包是直接面向线上用户的安装包。

4、集成回归发现问题

集成回归时发现bug，需要从release上拉取主分支代码进行修改。

因为在gitflow的流程内，为了保护代码的安全性防止需求污染，在集成后是不允许合并需求分支在当前版本分支内，bugfix的分支可以合入release里。

如果在集成时间节点之前，需求还是有bug未修复，但产品需要本次需求跟车发版，待修复问题不严重的情况下，可以先把需求分支集成在内，在整体回归测试阶段时，通过bugfix分支集成进入release分支内。

5、覆盖安装

覆盖安装环节是客户端集成回归测试中不可缺失的一个环节，对应线上绝大部分升级app安装的场景。

为什么要做覆盖安装测试：
验证是否可以正常的进行版本覆盖。
app logo 开屏内容变更是否会被替换。
app内本地资源再覆盖安装时是否会被清除。如：发布视频作品储存草稿箱内，音视频本地的资源文件，用户聊天消息记录等，覆盖安装时应不会清除本地用户相关功能缓存。
覆盖场景：
高版本覆盖低版本
低版本覆盖高版本
相同版本覆盖

6、hotfix

hotfix俗称热修，为紧急修复问题发版而生，每次发布hotfix时需要新的版本号才可发版，需要注意的是，最新hotfix的版本号只是最小的一位做变更。

hotfix发版在线上用户感知是等于一个新的app包，尽量减少hotfix发版，用户会感知app天天更新的负面体验。

7、 影响其他业务模块

需求分支或者bugfix分支改动可能会对其他的底层模块相互关联，会导致修A时B出现问题，如何尽量规避此类风险。

1.研发同学给出具体影响范围
2.测试code review寻找代码内影响范围
3.业务经验积累

假如按照此流程图内来看，修改本次需求后，对应的背包/生成/moyo秀/游戏房的道具展示大小也都会更改，如果对应的也无妨未做回归测试，则可能会在线上产生展示问题。

此类测试的时间节点应在需求分支或bugfix分支集成前进行回归测试，如果发现问题，同步需求分支开发进行修改。
在每次需求开发的过程中，测试编写case时，就应联想到此需求是否会有其他影响范围。
在确定回测范围后，测试应提前做哪些相应准备：
1.拉回测群，提供回测文档
2.准备分支打好的二维码包并提供分支名称
3.阐述需求内容与改动点
4.阐述简要回测范围内容

8、集成后代码生效

在需求或bugfix集成到主分支后，是否生效，可能会出现如下问题：

在合并代码时有代码冲突，把修改的内容合丢的（很常见）。
他人在合并代码时有冲突未沟通，把本次修改的代码合丢。
合并后未报冲突，但底层其他内容对本次需求有影响，会导致本次修改内容不生效。
如果业务包含服务端功能开关，或者abtest时，命中不同实验通道是否会生效。（可能会存在功能开关/abtest控制字段重名或者未server未返回的情况，导致内容不生效）