代码工程必备能力—Commit 规范

最新推荐文章于 2025-10-28 15:51:21 发布

原创最新推荐文章于 2025-10-28 15:51:21 发布 · 6.7k 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#1024程序员节

Git是目前应用最为广泛的开源分布式版本控制系统，不论是对企业团队还是科研任务都需要掌握使用Git的技巧，文章重点在于总结如何使用Git的一些功能，包括讲述的文章、资源和个人的想法。

Git 官方网址：Git

一. Git Commit 的作用（干啥用的）

Git Commit：指的是提交说明，用于标注此次修改的内容以及需要提示的信息,官方给出的解释是：Record changes to the repository（记录添加到仓库当中的修改）。

提供一个场景来做理解：

代码团队合作编写项目A，我作为开发人员从 Github 拉取代码到本地创建了分支A_1,并在这个分支上做了修改。假定这个修改的内容是为项目代码的某个文件增加了功能模块，将这部分修改提交到缓存当中，执行：

git add .

我想将工程上传到Github当中并希望团队的负责人审查之后，将我的功能模块并入到主模块当中，这个时候就需要告诉这个负责人我修改了什么，尤其在面对非常多的提交的时候，让负责人尽快地定位到关键内容，查看Commit信息就显得非常重要了。

当然，Commit对于自己维护代码和查看工作进程等方面都有非常重要的作用，每一个计算机人员在使用Git管理工程时候都应当保有Commit的习惯。

二. Git Commit 的正确打开方式（怎么用）

Git Commit命令用于将更改记录(提交)到存储库。将索引的当前内容与描述更改的用户和日志消息一起存储在新的提交中，以下是Git Commit命令的具体参数列表

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
	   [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>)]
	   [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
	   [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
	   [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
	   [(--trailer <token>[(=|:)<value>])…] [-S[<keyid>]]
	   [--] [<pathspec>…]

常用的有三种参数形式：

1. 命令行直接添加修改信息

git commit -m "描述提交修改的信息"

2. 使用文本编辑器添加修改信息

git commit

直接使用指令会弹出电脑的默认编辑器，然后直接编辑内容即可。当保存（Ctrl + S）之后关闭编辑器就完成了此次提交。

3. -a 会先把所有已经track的文件改动`git add`进来，直接提交而不需要每次都先执行Git add .

git commit -a

4. -amend 是增补提交，会使用与当前提交节点相同的父节点进行一次新的提交，旧的提交将会被取消，这样就不需要为了修改Commit的内容而再次提交一次。

git commit --amend

关于Git Commit更多的详细使用方式：

廖雪峰：简单直接上手的Git Commit操作和讲解

易百教程：详细讲述了Git Commit和 Git Add 之间的恩怨情仇

官网：每一个参数的具体解释

可视化使用Commit教程：IDEA， SourceTree , TortoiseGit

一般每一个IDE只要右键都能够发现对应的Git选项，其中会集成一部分功能的可视化。

三. Git Commit 的行业规范（遵守的规矩）

Git Commit 最大的价值就是标注信息，那如何才能够最高效地标识清楚修改的内容就是Git Commit的最大意义。

目前，社区有多种 Commit message 的写法规范。本文介绍Angular 规范是目前使用最广的写法，比较合理和系统化，并且有配套的工具。前端框架Angular.js采用的就是该规范。

目的是：

可读性好，清晰，不必深入看代码即可了解当前commit的作用。
为 Code Reviewing做准备
方便跟踪工程历史
让其他的开发者在运行 git blame 的时候想跪谢
提高项目的整体质量，提高个人工程素质

以下是在GitHub 上查看提交修改时候的界面

来看其中具体的一条

按照这个标准，规定Commit的文字部分格式：

格式要求包括三个部分： Header,Body和Footer；其中，header 是必需的，body 和 footer 可以省略。

<type>(<scope>): <subject>
<BLANK LINE> #空行的意思
<body>
<BLANK LINE>
<footer>

1. Header：

Header部分只有一行，包括三个字段：type 、scope、subject

这三部分分别对应图片当中红蓝黄三个部分的内容，一个比较好的Commit信息，应当包含完全必要的修改内容。

type 用于说明 commit 的类别，只允许使用下面7个标识。 
> feat：新功能（feature）
> fix：修补bug 
> docs：文档（documentation）
> style： 格式（不影响代码运行的变动）
> refactor：重构（即不是新增功能，也不是修改bug的代码变动）
> test：增加测试
> chore：构建过程或辅助工具的变动

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

例如在Angular，可以是$location, $browser, $compile, $rootScope, ngHref, ngClick, ngView等。

如果修改影响了不止一个scope，你可以使用*代替。

subject是 commit 目的的简短描述，不超过50个字符。

其他注意事项：

以动词开头，使用第一人称现在时，比如change，而不是changed或changes,第一个字母小写,结尾不加句号（.）

2. Body

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

有两个注意点:

使用第一人称现在时，比如使用change而不是changed或changes。
永远别忘了第2行是空行
应该说明代码变动的动机，以及与以前行为的对比。

3. Footer

（1）不兼容变动

BREAKING CHANGE: isolate scope bindings definition has changed.

    To migrate the code follow the example below:

    Before:

    scope: {
      myAttr: 'attribute',
    }

    After:

    scope: {
      myAttr: '@',
    }

    The removed `inject` wasn't generaly useful for directives so there should be no code using it.

以BREAKING CHANGE开头的Footer,主要用在当前代码和上一个版本不适应的时候

（2）关闭 Issue

如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。