Git团队开发管理规范、GitFlow流程规范

旧城等待， 2022-08-30 15:50 321阅读 0赞

### Git团队开发管理规范、GitFlow流程规范 ###

*  Git管理规范
 *  一、Git代码仓库创建规范
 *   *  1.1 代码仓库创建规范
     *  1.2 Groups使用规范
     *  1.3 目录结构及权限介绍
     *  1.4 README文件规范
 *  二、代码提交规范（\*）
 *   *  2.1 commit三要素
     *  2..2 标题
     *   *  2.2.1 类型
         *  2.2.2 改动范围
         *  2.2.3 精简总结
     *  2.3 内容
     *  2.4 备注
 *  三、分支管理规范（\*）

# Git管理规范 #

# 一、Git代码仓库创建规范 #

## 1.1 代码仓库创建规范 ##

1.  项目创建需符合`Group`规范。
2.  创建项目必须添加`Project description`说明。
3.  每个项目都需要`README.md`文件。
4.  除文档说明类型仓库，所有代码仓库都需要`.gitignore`。

*注：有模板的项目，要以统一的模板创建项目*

## 1.2 Groups使用规范 ##

Group 分为 rule(技术行为规范)、lab（技术预研）、common(基础库)、realicloud(基础平台)、rexxox(产品)、customer(定制化开发项目)  
![img][]

## 1.3 目录结构及权限介绍 ##

*  rule - Internal
 *   *  主要用于存放技术行为规范相关资料
 *  lab - Internal
 *   *  主要用于存放技术预研，比如shader预研、售前demo技术预研等。
 *  common - Internal
 *   *  主要用于存放公共组件库，基础算法库
 *  rexxxud - Private
 *   *  主要用于存放底层基础能力平台相关微服务，如PaaS层的接口、网关鉴权服务等。
 *  rexxxb - Private
 *   *  主要存放产品相关业务代码，如应用中心小程序等。
 *  customer - Private
 *   *  主要存放客户制定化开发项目代码。

*权限说明：gitlab主要包括三种权限Private、Internal、Public，分别为只对组内用户开放、注册用户可见和公开，公司gitlab一般不使用Public*

## 1.4 README文件规范 ##

README文件结构如下：

<项目简介/Introduction>
    <快速使用/Quick start>
    <文档说明/Documentation>

*  `Introduction` 用于阐述项目基本情况和功能（是什么，用来做什么的）
 *  `Quick Start` 主要包括两部分内容：简易的安装部署说明(Deployment)和使用案例(Example)。
 *  `Documentation` 部分是核心的文档，对于大型项目可以使用超链接代替

参考：  
![img][img 1]

# 二、代码提交规范（\*） #

## 2.1 commit三要素 ##

提交规范一般包括：**标题（类型、精简总结）、内容、备注** 。其中**精简总结** 是必填的，**类型** 最好也填一下，其余都是选填。

## 2…2 标题 ##

标题分为 **类型** 、 **改动范围** 、 **精简总结** 三部分：

### 2.2.1 类型 ###

规范的主要类型如下：

*  feat：新功能或功能变更相关
 *  fix：修复bug相关
 *  docs：改动了文档，注释相关
 *  style：修改了代码格式化相关，如删除空格、改变缩进、单双引号切换、增删分号等，并不会影响代码逻辑
 *  refactor：重构代码，代码结构的调整相关（理论上不影响现有功能）
 *  perf：性能改动，性能、页面等优化相关
 *  test：增加或更改测试用例，单元测试相关
 *  build： 影响编译的更改相关，比如打包路径更改、npm过程更改等
 *  ci：持续集成方面的更改。现在有些build系统喜欢把ci功能使用yml描述。如有这种更改，建议使用ci
 *  chore：其它改动相关，比如文件的删除、构建流程修改、依赖库工具更新增加等
 *  revert：回滚版本相关

其实实际开发中最常用的就是 feat、fix 和 perf，git提交基本上都是实现需求，更改bug，性能优化。除了上述这些主要类型，我们也可以根据团队要求定制类型，毕竟规范是死的，人是活的嘛。比如为了大家更易读，我们只留几个常用的，并且全改成中文，如：

*  功能更改：新功能或功能变更相关
 *  修复bug：修复bug相关
 *  优化：性能改动，性能、页面等优化相关

没有好与不好之分，适合团队的就是最好的！

### 2.2.2 改动范围 ###

当项目划分为好几个模块的时候，指定改动的模块是很有必要的事情，这样在git提交记录中，很容易看出提交者更改的是哪个模块。比如本次修改了compiler（编译器）模块，下次修改了 router（路由）模块，一目了然。如：

*  compiler
 *  router

### 2.2.3 精简总结 ###

必填的精简总结是非常重要的，一般是是总结概括的文字。要让人一眼就能看出来主要提交了什么，是添加了功能还是解决了问题，同时它也是大多数git管理工具默认展示的一行。如果你写的标准，那么提交记录看起来就很漂亮很规整。例如：

fix: 修复了无限抽奖的bug

## 2.3 内容 ##

内容主要填写详细的改动内容，可换行。当然，不必像写一篇小作文似的长篇大论，毕竟我们程序员的时间还是很宝贵的。如果精简总结写的比较完美，内容不写也是没关系的。不过如果更改确实很多，并且时间充裕的话，把本次提交内容的实现、需求以及背景都填写，是很负责的做法。比如：

fix: 修复了无限抽奖的bug
    
    在网络不好时，多次抽奖的接口可以被重复调用。
    此次更改了抽奖接口的逻辑判定，在并发请求中……采用了……所以……。

## 2.4 备注 ##

备注看起来并不是那么重要，主要作用就是有一些额外的hook补充，比如提交记录之后，自动触发代码联动编译，或者自动生成git提交的通知。

# 三、分支管理规范（\*） #

![image-20210721143940869][]

[img]: /images/20220829/bbfe0e6ab5de4372b19ce1062d4f3fef.png
[img 1]: /images/20220829/47d003ce0b9c4108983385c24bf9a4de.png
[image-20210721143940869]: /images/20220829/abe1f4e77fb34cc3b05ee72733245841.png