# 提交规范

文档维护人: 木木(linqh@authine.com)

# 为什么需要规范

  • 提交记录清晰直观;
  • 代码变更易于跟踪,易于代码审查;
  • 规范化提交可接入自动化;

# Git 提交

# 提交(commit)

# 通用规范

请参考Angular commit guidelines规范, 了解统统规范,大体如下

<type>(<scope>): <subject> #header
// 空一行
<body>
// 空一行
<footer>
# Header 是必需的,Body 和 Footer 可以省略。
1
2
3
4
5
6

# 格式介绍

Header部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)。

# type

用于说明本次commit的类别,通用规范允许使用下面 7 个标识,当然也能自定义!!

  • feat:新功能(feature
  • fix:修补bug类的提交
  • docs:文档相关的
  • style: 样式调整,代码格式(不影响代码运行的变动)
  • refactor:重构(即不是新增功能,也不是修改bug的代码变动)
  • test:测试提交,比如单元测试
  • chore:构建过程或辅助工具的变动

若是需要借助Standard Version 来自动生成changelog

如果typefeatfix,则该 commit 默认出现在 changelog 之中。 其他情况(docs、chore、style、refactor、test)自行决定要不要放入changelog,建议是不要。

# scope

用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。

# subject

commit 目的的简短描述,不超过 50 个字符。

# Body

用于对本次 commit 的详细描述,可以分成多行。下面是一个范例。

More detailed explanatory text, if necessary. Wrap it to
about 72 characters or so.

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Use a hanging indent
1
2
3
4
5
6
7

一般用于关闭 issue(),常规姿势

# 逗号隔开,可以一次性关闭多个 issue
Closes #234
1
2

# 全局或者项目内使用 Comitizen

commitizen 全局与非全局

全局安装:提交的时侯直接git cz调用起交互式规范提交。

项目内安装(package.json 里面的 scripts 来处理):"commit": "git cz" -> npm run commit这种方式来唤起

# 工具支持

# 非工具党

若是不想借助工具的情况下,可以自定义git的提交模板来实现提交规范

git config --global commit.template #<模版文件路径(例如:xx/xx/template.txt)>
git config --global core.editor vim #(配置vim当编辑器)
1
2

# 分支(branch)

对于分支的管理,一个选择是遵循的社区的开始趋势,另外一个选择是结合业务的约定式

# Git Flow

最理想话的是走结合业务的git flow模式,不过太过繁琐

# 约定式

改动都开新分支,保持master最新。

比如开发新特征的其中一种常规姿势

  • git checkout -b 1.x-xx-feature
  • 产生多个commit的情况下,看情况处理
    • 很多通用的情况下,把该分支测试后变基到master,部分用到的話用cherry pick
    • 合并到测试线的情况,保留提交记录

以此类推,hotfix,bugfix这类就是热修复和隐患修复

WARNING

切忌,切忌,别在公共远程分支上变基(rebase),基本会导致所有协作的人都会冲突,

不怕被打可以试试。为减少冲突的情况,本地分支可以变基到远程分支上,本地来解决冲突。

还有 master 分支需要开启protected,不允许强推(-f)

为了保证换行符的一致性(统一 lf)

window 下开发的小伙伴需要全局设置下 git 的换行标准

git config --global core.autocrlf false

# 工具流

约定是约定,有些人不熟悉git原理和命令行的情况下,有这么几个工具可以方便处理git

# 教学资源