【开发规范系列】（三）代码提交规范

程序员朱永胜

发布于 2023-09-01 11:21:31

1.1K00

代码可运行

文章被收录于专栏：朱永胜的私房菜朱永胜的私房菜

运行总次数：0

代码可运行

规范

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

一、背景

每次提交代码到 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 可以是多个，中间用逗号分隔。

举例：

仅 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，少用，用于开发中的不完整提交，新工程开始时偶尔使用。