版本开发基本流程——Gitflow Workflow（三）

版本开发基本流程

我们使用Gitflow分支策略，结合代码托管平台Gitlab进行版本的开发管理。

参考a-successful-git-branching-model

遵循Gitflow进行项目版本开发过程中最关键的几部分就是：

• 代码提交
• 代码评审
• 待发布版本测试
• 版本发布
• 发布版本热修复

缺点：多版本同步开发不支持

Gitlab和Gerrit的比较

关于代码提交和代码评审我们有必要将Gitlab和Gerrit做一个简单的比较说明。

代码提交比较

Gitlab代码提交：

通过feature branch提交和直接提交到远程分支（直接提交忽略了代码评审，并且可能存在提交覆盖的风险（譬如采用“-f”进行提交），我们可以将远程分支设置为protected，从而禁止采用这种方式）。为了安全和代码评审的需要建议使用feature branch进行提交。

# 提交feature branch
git push origin my_feature_br

# 直接提交到远程分支dev上
git push origin HEAD:refs/heads/dev

Gerrit代码提交：

直接提交到远程分支的Gerrit暂存区（这是Gerrit在Git之上做的扩展“refs/for/{remote branch}”）。对于Developer来说就好像是把本地提交直接推送到远程分支一样。并且还有一个优点是，多个Developer往一个分支上的提交如果有merge conflict的话，Gerrit会在暂存区进行检查提示（每个Developer往Gerrit push后即进行merge conflict检查）。

git push origin HEAD:refs/for/dev

代码评审比较

Gitlab代码评审：

• Developer提交feature branch后，发起merge request，请求将feature branch合并入目标分支上
• Reviewer在接收到merge request后，进行代码评审，拉取feature branch到本地进行测试
• Reviewer评审通过后通知Maintainer进行合并操作
• Reviewer评审不通过，那么close merge request，Developer删除掉feature branch，本地修改后重新提交
• Maintainer合并请求

Gerrit代码评审：

• Developer提交后，添加Reviewer，发起评审请求
• Reviewer收到评审请求后，进行代码评审，下载patch（譬如cherry-pick）到本地进行测试
• Reviewer评审通过后通知Maintainer进行合并操作
• Reviewer评审不通过，Developer本地修改后重新提交（Gerrit通过changeid来管理一个patch的不同版本）
• Maintainer合并请求

Gerrit的暂存区和changeid是对Git的一个重大改善，对于Maintainer，Developer，Reviewer来说使用起来更方便。且Gerrit的评审，合并页面更平面化，使用起来便捷。由于我们采用Gitlab进行代码托管，因此我们需要符合Gitlab的使用习惯。初次使用可能会有些不太顺手，但是他能让你对项目工作流有个更清楚的理解。

基本流程各部分介绍

代码提交

为了Gitlab代码评审的需要，我们使用Gitflow的Feature Branch进行提交：

• Developer本地检出feature branch
• Developer完成开发提交到feature branch
• Developer push feature branch到Gitlab仓库

检出feature branch的三个点：

• Developer如果是在dev分支上开发下一个发布版本的feature，那就从dev检出
• Developer如果是在release candidate分支上进行bug fix，那就从release candidate分支上检出
• Developer如果是在hotfix分支上进行bug fix，那么就从hotfix分支上检出

代码评审

我们使用Gitlab进行代码评审：

• Developer在Gitlab上发起merge request，请求将feature branch合并入目标分支（从哪边检出的就合并入哪边）
• Reviewer收到请求后，进行代码评审，fetch feature branch到本地进行测试
• 测试通过后通知Maintainer合并请求，删除掉feature branch
• 测试不通过，close掉merge request，删除feature branch后通知Developer进行修改并重新提交

待发布版本测试

我们使用Gitflow的Release Candidate分支进行版本测试。

当前版本规划的feature全都合入到dev分支上之后，进入到“待发布版本测试”阶段。此阶段不再允许合入新的特性。测试人员对项目进行测试（功能测试，压力测试），反馈Bug给开发人员进行Bug修复。

同时下一个发布版本的feature此时可以合并入dev分支。在此之前禁止合入，不要将下一个版本的特性引入到当前版本里

• Maintainer从dev分支上检出Release Candiate分支：sdk_vx.y_rc，更新版本信息（记录当前版本引入了哪些feature），打tag：sdk_vx.y
• Tester对项目进行测试，反馈Bug给Developer
• Developer同步Gitlab仓库，检出本地追踪分支sdk_vx.y_rc，在其上进行Bug Fix
• Developer从sdk_vx.y_rc检出release feature分支，提交修复
• 进行“代码提交”“代码评审”
• Maintainer合并时根据需要打tag：sdk_vx.y-rcx

版本发布

我们使用Gitflow的master分支进行版本发布

版本测试通过后进入到“版本发布”阶段

不要在merge的时候删除Release Candidate分支：一些老旧的分支发布出去之后，可能需要脱离主分支再维护一段时间；Release Candidate分支需要被合并入master和dev两个分支上

• Maintainer将Release Candidate分支合并入master分支，并打tag：sdk_vx.y.z_release
• Maintainer将Release Candidate分支合并入dev分支
• 此时可以从Gitlab仓库上删除掉Release Candidate分支（或者再等一段时间再删除，以防一些客户还基于此需要引入一些feature。当然最好的方法使建议客户升级新版版，如果版本差异不大，客户可以接收的话）

发布版本热修复

我们使用Gitflow的Hotfix分支进行热修复。

hotfix分支需要merge到master分支和dev分支（如果当前Release Candidate分支没有结束，那么应该合入Release Candidate分支，这样后续合并Release Candidate分支到dev分支时，也会带入hotfix），不要在merge时提前删掉hotfix

发布出去的版本发现了严重Bug需要立即修复后进行发布，此时需要用到“发布后热修复”：

• Maintainer从master分支检出hotfix分支
• Developer同步Gitlab仓库，检出本地追踪分支hotfix_vx.y.z，在其上进行Bug Fix
• Developer从hotfix_vx.y.z检出hotfix feature分支，提交修复
• 进行“代码提交”“代码评审”
• 通过后Maintainer合并hotfix feature分支到hotfix_vx.y.z分支上
• Maintainer合并hotfix_vx.y.z分支到master分支，打tag：sdk_vx.y.z_release
• Maintainer合并hotfix_vx.y.z分支到dev分支（如果此时没有Release Candidate分支正在开发）
• Maintainer合并hotfix_vx.y.z分支到Release Candidate分支（如果此时有Release Candidate分支正在开发，这样当前的发布版本也会有这个hotfix，而且将来也会到dev上；否则Release Candidate合入master和dev时会merge冲突，甚至删掉这一hotfix），如果此时dev上的开发需要这一hotfix，那么可以将Release Candidate分支往dev分支合并一次。
• Maintainer删除掉hotfix_vx.y.z分支