Git代码版本控制流程

心已赠人 2021-07-27 02:08 474阅读 0赞

我们的项目使用Git作为代码仓库、和版本控制工具。

Git有几种Workflow，来管理代码版本变更流程，我们采用Gitflow Workflow流程。

![33382ac1298f040035ad4a9fa878b997.png][]

Gitflow Workflow，采用了master、develop、release、feature、hotfix等几个分支。master、develop分支的生命周期是永久的，release、feature、hotfix分支都是辅助分支，其生命周期是短暂的。

各个分支的作用及意义，见下。

### master分支 ###

master分支用于保存官方发布历史，与线上的版本一致。要确保任何时候从master分支都可以拿到处于可发布状态的代码。

一个工程只有一个master分支，创建Git工程后自动创建，生命周期为永久。

跟master分支打交道的分支有release分支、hotfix分支：

*  测试通过后，“配置管理员”（以下简称为“配管”）将release分支合并到master分支。
 *  线上紧急修复后，“配管”将hotfix分支合并回master分支。

release分支合并到master分支后，需要在master分支上打Tag（记录里程碑），标记官方发布的版本号。

版本号的命名规则

命名规则：v*x*.*y*.*z*

*  *x*： 大版本号，有重大功能发布时升位。
 *  *y*：中版本号，增加新功能或功能优化改进时升位。
 *  *z*：小版本号，有hotfix时升位。

“配管”负责在master分支上打Tag。

### develop分支 ###

develop是开发集成的分支，所有开发完成的代码提交到此分支。功能累积到一定程度或者周期性发布需要提测时，从此分支迁出代码到release分支，进行测试。要确保任何时候都可以从develop分支拿到最新开发进展的代码。

一个工程只有一个develop分支，最初由“配管”创建，生命周期为永久。

跟develop分支打交道的分支有release分支、hotfix分支、feature分支：

*  “开发主管”提测时，“配管”从develop分支迁出代码到release分支。
 *  release分支测试通过后，“配管”将release分支合并回develop分支。
 *  线上紧急修复后，“配管”将hotfix分支合并到develop分支。
 *  功能开发完成后，“开发主管”（需要多人协作开发的feature）或各个开发（独立开发的feature）将feature分支合并到develop分支。

### release分支（新的发布版本） ###

release是测试分支，用于测试某个待发布的版本。从develop分支迁出代码到release分支，冻结代码（除了修改bug），进行测试。测试通过后合并到master分支，正式发布。

release分支使得待发布版本的测试与新版本的开发活动可以并行，互不干扰。

一个工程有多个release分支，一个待测试的、准备发布的版本一个分支。release分支的生命周期不是永久的，最初起源于develop分支，最终归于master和develop分支。提测时，“配管”创建一个release分支；测试通过、合并到master分支及develop分支后，“配管”删除该分支。

跟release分支打交道的分支有develop分支、master分支：

*  “开发主管”提测时，“配管”从develop分支迁出代码、创建一个release分支。
 *  release分支测试通过后，“配管”将release分支合并到master分支，同时合并回develop分支。

release分支的命名规则

命名规则：release\_*x*.*y*.*z*：

x、y、z的意义，同master的Tag。因为release分支一般用于发布新功能或功能优化改进，所以x、y会有升位，z取0。

测试、开发修改bug，都是在release分支上进行。在此期间，应严禁新功能的代码并入release分支，应合并到develop分支。

### feature分支（新的功能） ###

feature分支是各个功能的开发分支，开发完成后合并到develop分支。

feature分支使得多个人可以并行开发，互不干扰。

一个工程有多个feature分支，一个feature一个分支。feature分支的生命周期不是永久的，最初起源于develop分支，最终也归于develop分支。开始开发一个新功能时，由“开发主管”或开发自己创建一个feature分支；功能开发完成、合并到develop分支后，“开发主管”或开发自己删除该分支。

跟feature分支打交道的分支只有develop分支：

*  对于需要多人协作开发的feature：“开发主管”从develop分支迁出代码、创建一个feature分支，然后通知给需要协作的各个开发；各个开发在此分支上提交代码。各个开发的代码都提交后，“开发主管”将该feature分支合并到develop分支，然后删除该分支。
 *  对于不需协作、开发可独立完成的feature：可以由开发自己从develop分支迁出代码、创建一个feature分支；开发完成后，开发自己将该feature分支合并到develop分支，然后删除该分支。

feature分支的命名规则

命名规则：feature\_*xxx*：

*xxx*为功能的名称，如notification（通知）、circle（圈子）等。

### hotfix分支（新的修复补丁） ###

hotfix分支用于紧急修复线上的bug。

hotfix分支使得线上bug的紧急修复，与待发布版本的测试、以及新版本的开发活动可以并行，互不干扰。

一个工程有多个hotfix分支，一次hotfix创建一个分支。hotfix分支的生命周期不是永久的，最初起源于master分支，最终归于master和develop分支。提出hotfix时，“配管”创建一个hotfix分支；bug修改完成、合并回master分支以及develop分支后，“配管”删除该分支。

跟hotfix分支打交道的分支有master分支、develop分支：

*   *  需要紧急修复线上bug时，“配管”从master分支的某个Tag（一般是最新的）迁出代码、创建一个hotfix分支。
     *  bug修改完成、测试通过后，“配管”将该hotfix分支合并回master分支，同时合并到develop分支。

hotfix分支的命名规则

命名规则：hotfix\_*yyyymmmdd*：

*yyyymmdd*为提出hotfix的日期，一般情况下hotfix的bug必须当天修复、发布。

hotfix分支合并回master分支后，需要在master分支上打一个Tag，标记当前版本，小版本号升位。

具体到一个工程中，各个阶段的具体流程为：

项目启动

![dd02e21f448173ca9649312dcfe27818.png][]

准备开发环境

![c25205f4e503c28be7651157b96999dc.png][]

测试流程

![42ab33c1856081002cdca4b27d02fe4b.png][]

发布流程：

![72a603649f9f159e9a409f86fedd1c5c.png][]

hotfix流程：

![678a40929149303cbcaf89235d3263cf.png][]

[33382ac1298f040035ad4a9fa878b997.png]: /images/20210726/d39e6785b5124fb3b44cce097e2e97f5.png
[dd02e21f448173ca9649312dcfe27818.png]: /images/20210726/ec39881b71094719949978980f9a8a8d.png
[c25205f4e503c28be7651157b96999dc.png]: /images/20210726/b350b1ba86f8427fa110da9cd93927b8.png
[42ab33c1856081002cdca4b27d02fe4b.png]: /images/20210726/c5549a0ff4794c319ccc0fa6bd2efdf9.png
[72a603649f9f159e9a409f86fedd1c5c.png]: /images/20210726/7dcfc20270e142988558a248edf55318.png
[678a40929149303cbcaf89235d3263cf.png]: /images/20210726/d1189197a7a042218833b7ac1be42651.png