Git Commit Message 指南
Git commit message 约定有助于在开发过程中保持一致性和清晰性。当多个开发者致力于一个项目时,一致的提交信息格式必不可少,以便每个人都能轻松理解进行了哪些更改、为什么进行更改以及这些更改的意义。这些约定让浏览提交历史记录、识别问题或缺陷以及对代码进行审查的过程变得更加容易。
目标
自动生成 CHANGELOG.md
在变更日志中使用以下三个部分:new features
、bug fixes
、breaking changes
。执行发布时可以通过脚本生成此列表。以及指向相关提交的链接。当然,你可以在实际发布前编辑此更改日志,但它会生成框架。
自上次发布以来所有主题(提交信息中的第一行)的列表:
|
|
此版本的更新功能
|
|
识别不重要的提交
这些是格式化更改(添加/删除空格/空行、缩进)、缺少分号、注释。因此,当你寻找某些更改时,可以忽略这些提交 - 此提交中没有逻辑更改。
二分时,你可以通过以下方式忽略这些内容:
|
|
改进代码质量
撰写得当的提交信息有助于开发者理解代码更改的目的和背景,从而提高代码质量。清晰简洁的信息有助于对代码进行审查,并帮助尽早识别潜在问题。
更轻松的协作
当团队成员遵循一致的提交信息惯例时,在项目上的协作会变得更加容易。每个人都可以快速掌握更改背后的意图,从而减少混淆和误传。这会促进更流畅的协作和高效的代码合并。
增强的代码历史记录
提交信息创建了代码更改的详细历史记录,提供了对项目演变情况的宝贵见解。标准化信息让跟踪特定功能或缺陷修复的进度变得更容易,有助于调试、重构和理解过去决策背后的基本原理。
简化项目管理
清晰的提交信息能让项目经理更轻松地监督任务的进度并识别依赖关系。结构良好的信息与敏捷方法保持一致,并提高整体项目的透明度。
改进文档
提交信息充当代码更改的文档。它们提供修改的简要摘要,以人类可读的格式捕获更改的本质。此文档有助于理解代码库,特别是对于处理项目不熟悉部分的新手或团队成员。
自动化和工具集成
标准化的提交信息有助于集成工具和自动化脚本。例如,一些工具可以基于提交信息自动生成变更日志、发行说明或文档。一致的格式可以更好地解析和处理提交信息。
版本控制历史记录
提交信息提供代码更改的时间顺序记录,如果需要,允许开发者轻松地恢复到代码库的先前版本。富有信息性的信息可帮助更容易地识别特定提交并了解代码在不同时间点的状态。
增强搜索和可追溯性
标准化的提交信息改善了版本控制系统内代码更改的可搜索性。开发者可以快速找到与特定关键字相关的提交,从而更轻松地追踪特定功能或缺陷的历史记录。这可以让问题解决变得更快,并促进持续改进。
专业性和团队文化
采用一致的提交信息惯例体现了对软件开发的专业和有条理的方法。这表明了维护高质量代码库的承诺,并在开发团队内培养协作和透明的文化。
Commit Message 格式
每条 commit message 都由 header
、body
和 footer
组成。header 具有特殊格式,其中包括 type
、 scope
和 subject
:
|
|
header是必需的,header 的 scope 是可选的。
body 和 footer 是可选的。
任何一行都不能超过 100 个字符!这使得在 GitHub 中以及各种 git 工具中更容易阅读。
footer 可以包含要关闭问题的引用。
Header
Header 只有一行,包含此次提交的简明扼要的更改说明,内容分为:type(必需)、scope(可选) 和 subject(必需)。
Type
必须是以下之一:
- build:影响构建系统或外部依赖项的更改(示例 scopes:gulp、broccoli、npm)
- ci:对 CI 配置文件和脚本的更改(示例 scopes:Travis、Circle、BrowserStack、SauceLabs)
- docs:仅限文档的更改
- feat:新特性
- fix:错误修复
- perf:提升性能的代码更改
- refactor:重构代码,不会修复错误也不添加特性的代码更改
- style:调整样式,不会影响代码含义的更改(空格、格式、缺失分号等)
- test:添加缺失的测试或更正现有测试
Scope
scope 用于描述提交影响范围。例如 api、model、compile 等…
如果没有更合适的范围,可以使用 *
。
Subject
subject 包含更改的简明扼要的说明:
- 以动词开头,使用第一人称现在时,比如 change,而不是 changed 或 changes
- 不要大写第一个字母
- 结尾不加句号
Body
和 subject 一样使用第一人称现在时。body 应包含更改的动机,并将其与先前的行为进行对比。
Footer
footer 包含任何有关 Breaking Changes 或者关闭相关 issue 的信息。
Breaking Changes
所有重大更改都必须在 footer 中作为重大更改块提及,以单词 BREAKING CHANGE:
开头,后面应有一个或两个换行符。其余部分是更改的描述、理由和迁移说明。
|
|
关闭 issue
如果当前 commit 针对某个 issue,那么可以在 footer 部分关闭这个 issue 。
Closes #234
或在涉及多个 issue 的情况下:
Closes #123, #245, #992
Revert
如果提交回滚了以前的提交,其标题应以 revert:
开头,后跟已回滚提交的标题。它应该在正文中说明:This reverts commit <hash>.
,其中哈希是正在回滚的提交的 SHA。
示例
feat($browser): onUrlChange event (popstate/hashchange/polling)
Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available
Breaks $browser.onHashChange, which was removed (use onUrlChange instead)
fix($compile): couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not… Would be better to expect case insensitive, unfortunately jasmine does not allow to user regexps for throw expectations.
Closes #392 Breaks foo.bar api, foo.baz should be used instead
feat(directive): ng:disabled, ng:checked, ng:multiple, ng:readonly, ng:selected
New directives for proper binding these attributes in older browsers (IE). Added coresponding description, live examples and e2e tests.
Closes #351
style($location): add couple of missing semi colons
docs(guide): updated fixed docs from Google Docs
Couple of typos fixed:
- indentation
- batchLogbatchLog -> batchLog
- start periodic checking
- missing brace
Linter 工具
- git-commit-msg-linter:一个轻量级、独立、0 配置且令人愉悦的 git commit message linter。
- husky:当您提交或推送时,可以使用它来 lint commit messages、运行测试、lint 代码等等。Husky 支持所有客户端 Git hooks。