1 commit message 规范
commit message格式都包括三部分:Header,Body和Footer
- <type>(<scope>): <subject>
- <body>
- <footer>
复制代码 Header是必需的,Body和Footer则可以省略
1.1 Header
- Type(必需)
type用于说明git commit的类别,允许利用下面几个标识。
- feat:新功能(Feature)
"feat"用于表现引入新功能或特性的变动。这种变动通常是在代码库中新增的功能,而不仅仅是修复错误或举行代码重构。
- fix/to:修复bug。这些bug可能由QA团队发现,或由开发职员在开发过程中识别。
- fix关键字用于那些直接办理题目的提交。当创建一个包含必要更改的提交,并且这些更改可以或许直接修复已识别的bug时,应利用fix。这表明提交的代码引入相识决方案,并且题目已被立刻办理。
- to关键字则用于那些部分处置处罚题目的提交。在一些复杂的修复过程中,可能必要多个步调或多次提交来完全办理题目。在这种环境下,初始和中心的提交应利用to标志,表现它们为最终办理方案做出了贡献,但并未完全办理题目。最终办理题目的提交应利用fix标志,以表明题目已被彻底修复。
- docs:文档(Documentation)
“docs” 表现对文档的变动,这包括对代码库中的表明、README 文件或其他文档的修改。这个前缀的提交通常用于更新文档以反映代码的变动,或者提供更好的代码理解和利用说明。
- style: 格式(Format)
“style” 用于表现对代码格式的变动,这些变动不影响代码的运行。通常包括空格、缩进、换行等风格调整。
- refactor:重构(即不是新增功能,也不是修改bug的代码变动)
“refactor” 表现对代码的重构,即修改代码的结构和实现方式,但不影响其外部行为。重构的目的是改进代码的可读性、可维护性和性能,而不是引入新功能或修复错误。
- perf: 优化相关,好比提升性能、体验
“perf” 表现与性能优化相关的变动。这可能包括对算法、数据结构或代码实现的修改,以进步代码的实行效率和用户体验。
- test:增长测试
“test” 表现增长测试,包括单位测试、集成测试或其他范例的测试。
- chore:构建过程或辅助工具的变动
“chore” 表现对构建过程或辅助工具的变动。这可能包括更新构建脚本、配置文件或其他与构建和工具相关的内容。
- revert:回滚到上一个版本
“revert” 用于回滚到从前的版本,撤销之前的提交。
- merge:代码合并
“merge” 表现举行代码合并,通常是在分支开发完成后将代码合并回主线。
- sync:同步主线或分支的Bug
“sync” 表现同步主线或分支的 Bug,通常用于办来由于合并而引入的题目。
- Scope(可选)
scope用于说明 commit 影响的范围,好比数据层、控制层、视图层等等,视项目差别而差别。
例如修改了Dao或者Controller,则可以添加表现这些范围受到影响,这有助于更清晰地理解提交的变动影响范围。例如:
- feat(Controller): 添加用户登录功能
复制代码 这个提交消息中,Controller 是 scope,表现这次提交影响了控制层。
- fix(DataAccess): 修复数据查询逻辑
复制代码 这个提交消息中,DataAccess 是 scope,表现这次提交影响了数据访问层。
如果你的修改影响了不止一个scope,你可以利用*取代。
- Subject(必需)
subject是 commit 目的的简短形貌,不超过50个字符。规范如下:
- 以动词开头,利用第一人称如今时,好比change,而不是changed或changes
- 第一个字母小写
- 结尾不加句号(.)
例如:
- feat(UserAuth): implement user authentication
复制代码 这个提交消息中,implement user authentication 是 subject,简洁明了地形貌了引入用户认证功能的目的。
- fix(Validation): correct input validation logic
复制代码 这个提交消息中,correct input validation logic 是 subject,清晰地说明了修复输入验证逻辑的目的。
1.2 Body
Body 部分是对本次 commit 的具体形貌,可以分成多行。Body编写有两个留意点。
- 利用第一人称如今时,好比利用change而不是changed或changes。这有助于使形貌更加直观和连贯,增强可读性。
- 应该说明代码变动的动机,以及与从前行为的对比。 Body 部分不仅仅是形貌代码的变动,还应该表明为什么举行这个变动,以及与之前的代码行为相比有哪些改进。这有助于其他开发者更好地理解代码变动的背后动机和意图。
1.3 Footer
Footer 部分只用于两种环境。
- 不兼容变动
如果当前代码与上一个版本不兼容,则 Footer 部分以BREAKING CHANGE开头,背面是对变动的形貌、以及变动来由和迁移方法。
- 关闭 Issue
如果当前 commit 针对某个issue,那么可以在 Footer 部分关闭这个 issue 。
也可以一次关闭多个 issue 。
1.4 示例
- 添加用户配置文件编辑功能
- feat(UserProfile): add user profile editing feature
- This commit introduces a new feature that allows users to edit their profiles
- directly from the user interface. The motivation behind this change is to
- enhance user interaction and provide a more seamless experience.
- Previously, users had to navigate to a separate editing page to update their
- profile information. With this new feature, users can now make changes
- efficiently from their profile page, eliminating unnecessary steps in the
- workflow.
- Changes included in this commit:
- - Added a new 'Edit Profile' button on the user profile page.
- - Implemented frontend components for profile editing.
- - Updated backend API to handle profile updates securely.
- By streamlining the profile editing process, we aim to improve overall user
- satisfaction and make our application more user-friendly. This enhancement is
- in response to user feedback, addressing the need for a more intuitive and
- accessible way to modify profile details.
- Closes #234
复制代码 - 改正输入验证逻辑
- fix(Validation): correct input validation logic
- This commit addresses an issue related to input validation logic in theapplication. Previously, the validation process was not handling certain edgecases correctly, leading to unexpected behavior in specific scenarios.To resolve this issue, the validation logic has been revised to properlyhandle various input scenarios. This ensures that user input is thoroughlyvalidated, reducing the likelihood of errors in the application.The changes made in this commit include:- Correcting boundary checks for user input.- Improving error messages for better user guidance.These adjustments align with our commitment to delivering a robust andreliable application experience.Closes #123
复制代码 - 优化数据库查询
- refactor(DataAccess): optimize database queries
- In this commit, we have refactored the data access layer to optimize database
- queries and improve overall system performance. The existing query structure
- was identified as a bottleneck during performance testing, leading to longer
- response times.
- Changes made in this commit:
- - Reorganized database queries to reduce redundant operations.
- - Utilized database indexing for faster data retrieval.
- By optimizing database queries, we expect to see a significant improvement in
- system responsiveness and user experience.
- Closes #456
复制代码 2 git commit 工具
2.1 commitizen
Commitizen是一个强大的工具,用于撰写及格的 Git 提交消息。利用 Commitizen 可以帮助团队遵照同一的提交消息规范,使提交历史更加清晰和易读。
首先,通过以下下令全局安装 Commitizen:
- npm install -g commitizen
复制代码 然后,在项目目录里,运行下面的下令,使其支持 Angular 的 Commit message 格式。
- commitizen init cz-conventional-changelog --save --save-exact
复制代码 这个下令会配置项目,使其支持 Angular 规范的 Commit Message。在实行下令时,你可以选择其他预定义的规范或者创建自定义规范。
之后,当你实行 git commit 下令时,将其替换为 git cz。此时,Commitizen 将引导你通过一个交互式的界面,以生成符合规范的 Commit Message。
在这个交互式界面中,你可以选择提交的范例(feat、fix、docs 等)、影响的范围(scope)、简短的形貌(subject)以及其他相关信息。通过这种方式,可以确保提交消息符合规范,并提供了更多的上下文信息,便于他人理解变动的目的。
利用 Commitizen 和规范化的提交消息格式,有助于进步代码库的可读性,方便生成自动化的变动日志,并促使开发者更注意写出清晰、明白的提交消息。
2.2 commitlint
commitlint是一个用于检查提交消息是否符合指定规范的工具。它可以帮助团队确保 Git 提交消息的一致性和规范性,尤其是当项目采用雷同 Angular Commit Message Conventions 的规范时。
- 安装 Commitlint
首先,你必要安装 commitlint 及其相关的配置和规则。通常,@commitlint/config-conventional 是与 Angular 规范兼容的配置。
- npm install --save-dev @commitlint/config-conventional @commitlint/cli
复制代码 - 配置 Commitlint
在项目根目录下创建 commitlint.config.js 文件,并添加如下内容:
- module.exports = {
- extends: ['@commitlint/config-conventional'],
- };
复制代码 这个配置文件利用了 @commitlint/config-conventional 中预定义的规则,确保符合常见的提交规范。
- 配置Git钩子
你可以利用 Husky 钩子工具来在提交前运行 commitlint。首先,安装 Husky:
- bashCopy code
- npm install --save-dev husky
复制代码 然后,在 package.json 中添加以下配置:
- jsonCopy code
- "husky": {
- "hooks": {
- "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
- }
- }
复制代码 如许配置后,每次提交前都会自动运行 commitlint 检查提交消息是否符合规范。
3 生成Change log
如果你的全部 Commit 都符合 Angular 格式,那么发布新版本时, Change log 就可以用脚本自动生成(例1,例2)。
生成的文档包括以下三个部分。
- New features(新特性)
- Bug fixes(bug修复)
- Breaking changes(庞大变动)
每个部分都会罗列相关的 commit ,并且有指向这些 commit 的链接。当然,生成的文档允许手动修改,所以发布前,你还可以添加其他内容。
conventional-changelog 就是生成 Change log 的工具,运行下面的下令即可。
- npm install -g conventional-changelog
- cd my-project
- conventional-changelog -p angular -i CHANGELOG.md -w
复制代码 上面下令不会覆盖从前的 Change log,只会在CHANGELOG.md的头部加上自从前次发布以来的变动。
如果你想生成全部发布的 Change log,要改为运行下面的下令。
- conventional-changelog -p angular -i CHANGELOG.md -w -r 0
复制代码 为了方便利用,可以将其写入package.json的scripts字段。
- { "scripts": { "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0
- " }}
复制代码 以后,直接运行下面的下令即可。
这个自动化流程不仅简化了 Change log 的生成过程,还确保了记录项目变动的一致性和正确性。生成的文档会按照新特性、bug 修复和庞大变动平分类,方便用户快速相识每个版本的变动环境。
4 参考资料
- 怎样规范你的Git commit?—阿里云开发者
- Commit message 和 Change log 编写指南—阮一峰的网络日志
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |