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

Git管理规范

一、Git代码仓库创建规范

1.1 代码仓库创建规范

  1. 项目创建需符合Group规范。

  2. 创建项目必须添加Project description说明。

  3. 每个项目都需要README.md文件。

  4. 除文档说明类型仓库,所有代码仓库都需要.gitignore

注:有模板的项目,要以统一的模板创建项目

1.2 Groups使用规范

Group 分为 rule(技术行为规范)、lab(技术预研)、common(基础库)、realicloud(基础平台)、rexxox(产品)、customer(定制化开发项目)
Git团队开发管理规范、GitFlow开发规范

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 部分是核心的文档,对于大型项目可以使用超链接代替

参考:
Git团队开发管理规范、GitFlow开发规范

二、代码提交规范(*)

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提交的通知。

三、仓库代码规范(*)

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

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

上一篇:类型“Readonly<{}>”上不存在属性“count”。


下一篇:lletcode-114. 二叉树展开为链表