【开发规范系列】(三)代码提交规范

简介: 【开发规范系列】(三)代码提交规范

首发博客地址[1]

系列文章地址[2]


规范

  1. 切忌一次大量提交代码,每次 fix 或 feat 一个功能即需要提交到本地,可以不提交到远程
  2. 提交代码前必须先拉代码
  3. 一般情况下 不得强制提交
  4. 一个新功能拉取单独的分支开发,开发完后再合并到主分支上
  5. 禁止无意义说明提交
  6. 通常需要每天下班前推送本地仓库到远程仓库中

一、背景

每次提交代码到 Git 仓库时,都需要写 commit message。通常情况下,commit message 应该清晰明了,说明本次提交的目的和具体操作等。然而,在日常开发中,开发者们提交的 commit message 千差万别,中英文混用,导致后续代码维护成本很高,有时候甚至自己都不知道修复的是什么问题。因此,为了解决这些问题,我们希望通过一种方式来监控用户的 git commit message,以提高代码规范,提高开发效率。

commit message

二、约定

我们要求所有项目的 Commit Log 都遵循一个精确的格式,以增加可读性,便于查看变更历史,并养成良好的 git 使用习惯。我们将这个规范作为 git hook 的 commit-msg 和 pre-receive 执行,不符合规范的 commit 无法提交。全面执行后,可以自动执行以下操作:

  • 平台工具包可以直接根据 commit log 生成每次版本的 changelog。
  • 上线申请系统可以自动附带本次上线的 commit log。
  • 要求每次提交都认真思考,保持 commit log 的整洁性,每次 commit 都要具有局部完整性。

三、Commit Log Format

Commit Log 包含三个部分:header、body、footer。其中,header 是必需的,格式固定,body 在必要时用于详细解释变更。

commit log 格式如下:

<types>(<scopes>): <subject>
<空行>
<body>
<空行>
<footer>

注意:冒号后面必须有一个小写空格,types 和 scopes 可以是多个,中间用逗号分隔。

举例:

  1. 仅 header:
fix(service,dao): 修改产品类型时不过滤产品Type
仅header,涉及模块较多用*代替
refactor(*): 修改DTO模型前缀
有header和body
fix(language-service): Improve signature selection for pipes with args
Pipes with arguments like `slice:0` or `slice:0:1` should not produce
diagnostic errors.
有header、body、footer
func(core,logic): 添加礼包审核
添加商品编辑审核状态和回调,blablablabla
PRD:https://km.sankuai.com/page/194127085

1、Type

英文,小写。必须是以下中的一个或多个:

  • func: function,小功能。注意:feat 改成 func 了,避免大家按 feature 这个大粒度来提交,期望是按小功能点分批提交,另外避免跟 feature 分支规范混淆。
  • fix: bug 修复,包括编码过程中的逻辑修复,不特指线上 bug 修复。
  • refactor: 重构代码,非 bug 修复和性能优化,包括编码过程中的代码结构调整,不特指重构项目。
  • impr: improvement,小的代码设计改进。
  • perf: 性能优化。
  • apm: 仅监控打点、异常日志处理相关。
  • chore: 无关紧要的改动,例如删除用不到的注解、调整日志内容等。
  • jvm: 仅 JVM 参数变更。
  • pom: 仅依赖和版本变化。
  • conf: 仅配置变化,Spring 配置、properties 文件。
  • docs: 仅文档变更。
  • style: 代码格式调整,如 import 清理,代码格式化。
  • test: 单测和自动化 case 相关。
  • typo: 修复小的拼写错误。
  • wip: work in progress,少用,用于开发中的不完整提交,新工程开始时偶尔使用。

2、Scope

英文,小写。表示变更的包或模块范围,可以是多个组合,如果涉及范围较大,可以用*代替。各服务可以自行定义,组内同学可以轻易理解。通用 scope 列表如下:

  • dto: dto 结构变化。
  • core: core 包。
  • service: service 层代码。
  • dao: dao 层代码。
  • sql: sql 代码变更。

除了上述通用字段外,各方向可以自行定义关键字。例如,以下是商品平台中定义的字段:

  • price: 价格相关。
  • stock: 库存相关。
  • product: 商品相关。
  • idl: IDL 文件变化。

3、Subject

中文。简要描述修改,结尾不要有句号。

4、Body

中文。修改的背景(为什么做这次修改),说明修改逻辑。

5、Footer

中文。可以放置需求 wiki 或 task 链接,对以后其他同学查看很有用。

四、使用插件生成日志

commitizen

安装该插件后,在提交页面会有一个按钮

commitizen buttoncommitizen promptcommitizen example

参考资料

[1]

首发博客地址: https://blog.zysicyj.top/

[2]

系列文章地址: https://blog.zysicyj.top/categories/技术文章/后端技术/系列文章/开发规范/

本文由 mdnice 多平台发布

相关文章
|
7月前
|
前端开发 JavaScript
工作中代码书写规范
前端代码规范增进代码整洁与团队协作,降低维护成本。包括代码规范、风格和注释建议:选择编程语言对应的编码规范,统一命名、缩进和换行规则;注重代码风格的一致性、简洁性和可配置性;注释要简洁明了,位于关键位置。通过制定规范文档、使用代码检查工具、定期代码审查和鼓励改进来执行规范,提升团队效率和代码质量。
75 0
|
缓存 JSON JavaScript
37 # commonjs 规范流程梳理
37 # commonjs 规范流程梳理
48 0
|
存储 设计模式 人工智能
规范:前端代码开发规范
规范:前端代码开发规范
1611 0
|
7月前
|
小程序 JavaScript 容器
|
前端开发 JavaScript
|
数据采集 算法 Shell
【C#编程最佳实践 七】代码书写规范实践
【C#编程最佳实践 七】代码书写规范实践
137 0
【C#编程最佳实践 七】代码书写规范实践
|
程序员
代码的规范
代码的规范
166 0
|
算法 IDE 程序员
代码编写规范
代码编写规范
|
开发工具 git
代码统一风格、代码规范和提交规范
1、安装模块 全局安装 eslint、commitlint 、 check-prettier npm install eslint commitlint check-prettier -g 本地安装 npm install eslint-config-prettier  stylelint  stylelint-config-prettier stylelint-config-standard husky  @commitlint/config-conventional -D VSCode 安装 Eslint和Prettier插件
158 0
|
运维 JavaScript 开发工具
项目开发规范
项目开发规范
381 0