概述

本流程的分支管理维护两个长期分支，Master分支为主分支；维护两类临时分支：BUG修复分支和特性分支。Stable分支总是落后于或等于Master分支的进度，且Stable分支总是由Master分支合并而来，当整个产品进行大的功能升级或者达到版本发布条件时，合并Master分支到Stable分支。

分支划分

Master分支

Master分支为主分支，上面的代码认为是可靠的，可直接给客户现场升级。开发人员的代码只能提交到Master分支，Master分支开启分支保护，只能通过Merge Request方式提交。

Feature分支

特性(Feature)分支又叫做功能分支，是为了开发某种特定功能而创建的临时分支，是从Master分支上分出来的，功能分支仅能合并到Master分支上，不能跳过Master分支直接合并到Stable分支，Master分支接收功能分支的合并后可将功能分支删除。 feature分支命名规范：feature_${功能名称}。比如： feature_sms 代表短信功能分支

BUGFix分支

BUG 修复分支在当系统出现 BUG 时创建，也是一个临时分支。它基于最新的 Master 分支创建，BUG 修复后合并到 Master 分支，合并后可将该分支删除。对于重大 BUG，经评估后可将该BUG分支同时合并到 Master 和 Stable 分支，相当于Stable分支发布了一个新版本。

BUG 修复分支的创建方式：

在 GitLab 上提一个 issues ,标记为 BUG 类型，并做详细描述。这个 issue 会被自动分配一个编号如#2。
在 GitLab 的该 issue 上点击创建分支按钮，此时系统会自动创建一个名称为2-的分支，这个分支就用于修复 BUG#2 。

分支管理

操作实例

分支合并操作流程如下：

在本地创建特性分支feature_sms。

1

git checkout -b feature_sms

本地进行多次commit后完成开发和自测。
将feature_sms分支推送到远端。

可以在远端管理界面上看到这个新分支

发起Merge Request请求并做详细描述。在管理界面点击Merge Request按钮发起合并请求，填写详细描述。
对于简单的修改需求，分支管理员进行代码走读和简单功能验证即可接收合并；对于核心业务，须统一安排测试、评审测试用例走完测试流程后方可进行合并。

解决冲突

当向远端推送了Merge Request请求后，分支管理员在合并分支的时候的时候可能会出现冲突，此时应关闭该Merge Request由发起合并请求者在本地解决冲突后重新发起Merge Request。

案例分析

-w753

此时Git提示冲突，无法合并。应关闭该合并请求然后通知开发者，让开发者解决冲突再次提交合并请求。

解决完冲突再push一下feature_sms分支，就会发现Accept Merge Request按钮可用了。 -c706

版本发布

当系统经评估完成一个阶段性成果后，可考虑新版本发布。发布新版本时需在GitLab上将Master分支上的代码合并到Stable分支，打上TAG用于标识系统版本号。此操作经项目组批准后，由Stable分支管理员进行操作。 -w762

版本发布时应注明新版本特性列表和上一版本的升级SQL。

版本号规范

主版本号、子版本号、阶段版本号仅在合并到Stable分支时，由Stable分支管理员统一在系统代码中更新。

-c502

日期版本号在每一次升级系统时都在系统参数中维护。

分支管理员

对于一般性的功能提交或BUG修复提交，需由至少2名Master分支管理员进行代码走读和业务了解，2人均同意后方可接受该Merge Request。

对于涉及核心业务的提交，需组先编写测试用例进行测试，测试无误后项目组内开会评审，评审的内容包括但不限于测试用例的覆盖率、代码走读、业务相关性讨论等。待评审通过后 Stable 分支的管理员可接受该 Merge Request。

注意事项

切换分支时需先将当前分支未保存的工作提交到本地仓库，或用git stash命令暂存。否则该分支上的改动会被签入到待切换分支。
每条分支上的代码可以完成某个小功能点为粒度创建多次提交，往远端推送的频次无要求。
每条分支在功能开发完毕且测试无误后方可发起Merge Request，不允许未开发完毕就发起合并请求，浪费人力成本。

总结

新的分支管理流程范适用频繁部署、持续集成的要求:

通常，客户要求两三天就要升级一项功能，此时如果基于GitFlow，单是走完整个分支管理流程就废了半天时间，况且为了某个小功能单独发布一个版本是不合适的。

新的管理流程在源头上保证了 master 分支的代码是可靠的，是可以发布的，将审核工作放到平时，化整为零，避免了项目发布时统一测试可能遇到的业务遗忘、用例考虑不全等问题。

Stable分支存在的意义：

对于进入维护期的项目，在例行升级时候只升Stable分支，保证系统功能相对稳定。且要求了每次Stable分支发布版本时，都要整理升级脚本，这就使得升级工作变得简单了。

拓展阅读

首先，多人协作的情况，我们通常会 fork团队项目主仓库到自己的托管空间下，然后 Clone 到本地进行开发,假设团队项目的托管地址为：

https://github.com/fe/github-flow

此时主仓库项目下的固定分支两个，分别是 master，develop。

Clone 到本地：

git clone git@github.com:fe/github-flow.git 假设上面主仓库 fork 之后的项目地址为：

https://github.com/xxx/github-flow

Fork 出来的仓库完全属于你自己，你可以任意修改该仓库的代码及配置，但是除非你向项目主仓库提交 pull request，并且被接受通过，你才可以将你fork 仓库修改的代码合并到主仓库，否则不会对主仓库产生任何影响。

此时可以在控制台输入 git remote -v 命令查看当前远端仓库的地址，输出如下：

origin  git@github.com:xxx/github-flow.git (fetch)
origin  git@github.com:xxx/github-flow.git (push)

可以看出该地址的远端（origin）为刚刚 fork 到自己的托管空间下项目地址。

接下来我们可以设置一个名字为 upstream 的上游地址，也就是我们项目主仓库的地址在命令行执行：

1

git remote add upstream git@github.com:fe/github-flow.git

添加一个别名为upstream(上游)的地址，指向之前 fork 的原项目仓库地址。再次执行 git remote -v 控制台输出如下：

origin  git@github.com:xxx/github-flow.git (fetch)
origin  git@github.com:xxx/github-flow.git (push)
upstream    git@github.com:fe/github-flow.git (fetch)
upstream    git@github.com:fe/github-flow.git (push)

设置上游地址的目的是当我们通过 pull request 的形式提到主仓库之后，本地仓库需要同步主仓库的代码，并及时更新到 origin（远端）仓库，保证自己托管空间下本地和远端仓库的代码都是最新的。

之后运行下面几条命令，就可以保持本地仓库与上游（upstream）仓库同步了

1
2
3


git fetch upstream
git checkout master
git merge upstream/master

命令速览

查看分支

1
2
3
4
5


$ git branch
----------
* develop
  hotfix_lisi_20180311_测试分支
  master

创建分支

1
2


git branch <name>
例：$ git branch feature_zhangsan_20190310_停上电事件处理

切换分支

1
2
3


$ git checkout develop
-----------
Switched to branch 'develop'

创建+切换分支

1
2


$ git checkout -b hotfix_lisi_20180311_测试分支
Switched to a new branch 'hotfix_lisi_20180311_测试分支'

删除分支

1
2
3
4


git branch -d <name>
例：$ git branch -d feature_zhangsan_201903101010—_功能一
--------------
Deleted branch feature_zhangsan_201903101010—_功能二 (was 7ca7803).

从远程合并分支

1

git pull origin <远程分支name>

文章目录

Git 协同工作流实战二（最佳实践）

概述