版本控制系统(GIT)分支管理规范

转载

GIT工作流简介

功能驱动开发

"功能驱动式开发"(Feature-driven development,简称FDD).

它指的是,需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。

如果我们开发的内容在功能的角度上就存在不相容,无法合并,则这种工作流未必合适.从项目设计上讲应该尽量避免这种情况的出现,否则,建议分割项目来解决.

Git flow(Git 工作流)

Git工作流比喻项目像流水一样顺畅自然的向前流动,不会发生冲击,对撞,甚至漩涡.

image.png

目前用的比较广泛的工作流有三种:

  • Git flow
  • Github flow
  • Gitlab flow

针对目前的项目状况,本文采用的是最早诞生,并得到广泛应用的Git flow。

Git flow

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

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

image.png

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

功能分支(feature branch)
补丁分支(hotfix branch)
预发分支(release branch)
一旦完成开发,它们就会被合并进develop或master,然后被删除。

GIT Flow总览

image.png

主分支Master

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

对应到目前团队中使用的Gitlab,我们建议使用Master作为主分支并设置分支保护(默认设置),每次发布打上Tag,如: 0.1, 0.2或0.3

image.png

开发分支Develop

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

image.png

如果想正式对外发布,就在Master分支上,对Develop分支进行"合并"(merge)。

由于Gitlab中默认对Master设置了分支保护(这个设置允许取消,如果存在多人开发的项目,不建议取消),所以,当需要合并到Master的时候需要在Gitlab里提交合并申请,由项目管理员合并.

功能分支

功能分支属于临时性分支,一般合并完就会删除.

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

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

比如我们正在开发分支中开发小宇睿联的需求,这个过程中来了5M微循环的迁移任务,这个时候,就可以从Develop分支中拉出一个5M的功能分支进行开发,避免两个需求开发重叠.

可能大家还会有疑问,开发分支里已经有一部分小宇睿联的内容,拉出来分支会不会有影响,这种情况可以评估下,如果存在冲突的话可以从Develop分支中向上回溯到一个合适的Commit拉出功能分支来.

某些情况下,新功能可能需要在线上的版本保持一致,可以从Master里拉出功能分支,也可以.

image.png

实际应用功能分支的时候,存在以下几种情况:

  1. 正常迭代,周期性的功能需求
  2. 产品型需求,这种需求的周期很长,需求和项目的主线有很大偏差,同时要求不跟着主板本迭代,如: 本地化部署

第一种情况,按照标准的feature分支工作流开展即可,不再赘述.

产品型需求

这种分支建议以production-分支定义,在功能迭代完成后直接在production-分支上拉出release分支提测,测试完成后,合并回production分支,同时在production分支上打上tag.

由于这种分支并不合并到主干,所以上线的代码都体现在production分支上,如果线上有bug需要修复,在tag上拉出fixbug分支修复即可.

这种分支实际上相当于一个独立的项目进行迭代,和本文阐述的分支管理主旨并不相符.

[图片来不及画]

预发布分支

它是指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。

预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支,合并完后删除分支。

它的命名,可以采用release-*的形式。

比如我们小宇睿联的需求已经开发完成了需要提测,这个时候我们可以从Develop中拉去一个预发布分支,提交测试.测试过程中出现了bug,就在这个分支里修复,当小宇睿联上线后,把分支合并回Develop,同时合并到Master分支,并在Master分支上打上Tag.

修补bug分支

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

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

image.png

bug分支在提交的时候,如果存在release分支,需要同时合并到release分支,避免release分支上线的时候,合并到master有冲突.

Git合并的命令推荐

|

<pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">git checkout develop Switched to branch 'develop' git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
git branch -d myfeature Deleted branch myfeature (was 05e9557). git push origin develop</pre>

|

默认情况下,Git执行"快进式合并"(fast-farward merge),会直接将myfeature分支指向Develop分支。使用--no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法。

image.png

分支命名规范

<colgroup><col><col><col></colgroup>
| 分支类型 | 命名 | 说明 |
| 主干 | master |
|
| 开发分支 | develop |
|
| 功能分支 | feature-* | 使用禅道的需求编号(如果对应的需求编号过多,也可以使用拼音缩写) |
| 预发布分支 | release-* | 使用日期+版本号 , 如: 20181016-1.2 |
| bug分支 | fixbug-* hotfix-* | 使用禅道的bug工单号,或者根据当前tag版本号增加 |
| 产品分支 | production-* | 产品分支,对于独立进化的分支,如本地化部署 |

新平台开发场景指引

目前新平台开发场景大概有以下几种情形:

  1. 普通迭代
  2. 线上bug修复
  3. 功能提测
  4. 新的项目功能加入

针对这几种情形,我们依次给出指引

普通迭代

日常的迭代我们一般推荐在Develop下正常开发即可,提测的时候拉出Release-xxx分支提交测试,测试完了,如果需要上生产则分别合并到Develop和Master,同时在Master上打上Tag(Tag-x.x.x)标记,删除Release分支.如果,暂时不上生产则合并回Develop,暂时保留Release分支,等待发布到生产.

比如我们现在正在开发新能源迁移,这个时候并没有新的功能加入,我们只需要按照普通迭代开发即可.

线上bug修复

在Master分支里拉出bug-xxx分支修复bug,修复完成后提交测试,测试通过,分别合并到Develop和Master,再删除bug分支.

功能提测

提测的时候拉出Release-xxx分支提交测试,测试完了,如果需要上生产则分别合并到Develop和Master,同时在Master上打上Tag(Tag-x.x.x)标记,删除Release分支

新的项目功能加入

普通迭代过程中收到了新的需求开发,为了不造成影响,在Develop分支里拉出Feature分支开发功能需求,开发完成后,合并到Develop.提测的时候,在Develop中拉出Release-xxx分支提交测试,测试完毕参照功能提测.

常见问题

5M微循环作为一个独立分支,是面对客户独立部署,将来可能不希望跟着正常迭代走,在分支上该如何管理?

这种情况,由于存在两个线上环境,实际上等于存在两个Master分支,其中一个是5M的分支,它最终也会作为一个长期分支存在,后续的功能开发,或者Bug修复都在这个分支上拉出功能分支来进行,完成测试后再合并回5M的分支,这个工作流有点像Github flow(详见参考文档).

正常迭代过程中修复了一个bug可能涉及到其他功能分支,如何处理?

保险起见,最好在不同的分支里分别提交,这样做不可避免的会带来一些麻烦,所以,我们在项目的迭代周期上,一定不要太长,否则遗留的功能/测试分支太多,会给开发人员的开发带来麻烦.

新的功能开发完成提交了Release分支,如何保证旧的功能不会收新功能影响?

这个问题本质上并不是工作流的问题,这里也拿出来讲一下,解决这个问题,还是需要从测试着手,而测试分为两块,白盒测试和黑盒测试.对于开发人员,项目中开发的功能都需要有单元测试能够覆盖到,当新的功能开发完成后,完整的执行一遍单元测试,可以检查对旧功能是否造成影响.同样测试人员也会针对上线功能进行完成测试.

新能源迁移的功能分支,由于短期内无法上线,这些分支在测试完后,如何处理?

这些分支在功能开发完成后,就合并到了Develop分支了,提测生成的测试分支,由于暂时无法上线,暂时不要合并到主干,可以先合并回Develop分支.

新能源功能已经开发完成了,这个时候合并到了Develop,这个时候小宇睿联的又有新的需求需要开发,由于新能源短期内无法上线,目前线上的环境是小宇睿联的功能,如何处理?

这种情况,建议从Master里拉出Bug分支进行开发,流程参考Fix-bug.

Github flow工作流简介

Github flow 是Git flow的简化版,专门配合"持续发布"。它是 Github.com 使用的工作流程。

流程

它只有一个长期分支,就是master,因此用起来非常简单。

官方推荐的流程如下。

image.png

第一步:根据需求,从master拉出新分支,不区分功能分支或补丁分支。

第二步:新分支开发完成后,或者需要讨论的时候,就向master发起一个pull request(简称PR)。

第三步:Pull Request既是一个通知,让别人注意到你的请求,又是一种对话机制,大家一起评审和讨论你的代码。对话过程中,你还可以不断提交代码。

第四步:你的Pull Request被接受,合并进master,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)

扩展讨论

  1. 如何将现有代码切换过来
  2. 如何培训推广

GEMINI修改分支样例

迁移前分支状况

master 最新迭代分支

pro 生产环境分支

fat 测试环境分支

5m 5米微循环分支

迁移计划

1.从master新建一个develop分支

|

<pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">git checkout master
git checkout -b develop</pre>

|

2.把master分支重置到pro分支的分叉处,我的项目里查到的分叉处commit为 af8ac1ef66f3e2c932623eecd71296e19a2c2e9c

|

<pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">git.exe reset --hard af8ac1ef66f3e2c932623eecd71296e19a2c2e9c
git.exe merge remotes/origin/pro</pre>

|

最终达到的效果:

  1. master分支指向到了origin/pro
  2. develop分支指向到了最新代码
image.png
image.png

参考文档

Git工作流程

A successful Git branching model

Understanding the GitHub flow

GitHub Flow

推荐阅读更多精彩内容