Git工作流规范

Git基本原理及命令使用

Git简明教程

Git工作流使用方式选择

• 微型项目，使用集中式工作流。
• 小型项目，功能分支工作流。
• 中大型的互联网项目，不断需求迭代，一个版本接一个版本，参考并使用如下Git工作流。

Git工作流使用场景

当一个项目中有多个不同版本的需求迭代，每个版本由不同的开发人员参与开发，每个版本上线时间不一致。目前很符合大屏代理服务端接口的这种场景，可以遵循Git工作流规范。其他类似的项目模式，多人协作开发场景，亦可遵循此Git工作流规范。

Git工作流规范

Git工作流规范说明

1、 master分支是基础分支，永远是趋于最稳定的版本，并且受保护的，不允许直接merge其他分支到master分支。

release分支预发布环境测试通过，发起merge request，请参考如下步骤2。

Accept merge request完成后，通过legit平台或命令行方式创建本次上线的tag，并添加注释说明。（tag：需求上线里程碑，同时也用于代码回滚使用）

命令行方式：

1. 创建tag git -a ‘master.tag.2.8.0’ -m ‘添加注释说明’

2. 将tag推送到远程分支，git push origin master.tag.2.8.0

2、 release分支属于临时预发布分支，从master分支拉取，用于QA回归测试，冒烟测试，正式上线前期的测试。

• 2.1 当一个需求迭代版本需要上线，可以直接从master分支拉出release分支。

命令规范：release命名根据本次需求升级feature来定。比如：release_child_v4.1.0

• 2.2 release分支创建完成，将测试通过的feature/x_4.1.0分支代码通过legit代码平台发起merge request

  操作步骤 (不同平台可能略有差异，如Gitee跟Gitlab不同)：

1. 进入Merge Requests，点击 +New Merge Request
   选择Source branch（功能分支），Target branch（目标分支-release分支），点击Compare branches and continue
   

2. Title中简述本次变更内容

   Description中填写本次变更的详细内容：

   1、新增专辑详情页V2版本接口

   2、yyy

   3、zzz
   

3. 点击Changes查看本次版本变更详细代码，自己可以详细再过一遍代码看看是否还有问题。
   

4. 确认没有问题，点击 Submit merge request 按钮提交，并通知代码审核人完成代码审核和accept。

• 2.3 代码审核人，进入legit平台该项目中。

  操作步骤：

1. 点击Merge Requests，点击Changes查看代码变更，并做审核。

2. 代码审核未通过，通过增加Comment，并告知代码提交者进行修改，修改完成继续发起merge request。

3. 审核通过，点击Accept merge request 将代码合并到release分支。

3、 develop分支属于集成测试分支，从master分支拉取，多人开发的迭代版本集成到这上面，发布到测试环境的分支。

develop分支也算临时分支，需求迭代测试一段时间，可能会跟master版本差异较大，根据实际情况，考虑重新从master拉取分支，将各个feature分支代码合并进来，再发布到测试环境中。

因为项目中一般就一套测试环境，如果有多套，可以创建不同的develop分支，分开部署。

4、 local分支属于开发人员本地分支。

基本都是从基准代码master分支拉取的，一个功能模块新建一个分支，利用好git多分支的优势。

命令规范：feature/xxx_yyy_v4.1.0

5、 bugfix分支，从基准代码master分支拉取，bug修复完成同步到你的本地开发local分支和develop集成分支一份。

命名规范：bugfix/xxx_yyy_v4.1.0

分支清理：

当一个需求迭代版本代码开发完成，合并到master，打完tag上线平稳运行后 ，就可以将feature分支、release分支删除掉了。

需求迭代一个阶段后develop集成分支功能全部上线，下一个版本需求从master重新拉一个新的develop分支作为集成分支。

开发代码提交注释：

明确写清楚本次修改内容，尽量是每天提交一次，或者完成一个模块功能提交一次commit。

Git 标签版本号制定

Git tag 版本号规范：主版本号.次版本号.ISSUE版本号

示例：

Tag版本号：3.1.1

3：表示大版本，比如大的系统重构等。

1：表示功能迭代版本，每次新的需求迭代上线后 +1

1：表示ISSUE版本，在 3.1 功能版本下，修复一些列小问题，比如Bugfix等。修复一次版本 +1

版本升级举例：

儿童4.0.0.0需求上线，变更为：3.2.0

儿童4.0.0.0线上BUG修复，变更为：3.2.1