Git Commit 之道:规范化 Commit Message 写作指南

这篇具有很好参考价值的文章主要介绍了Git Commit 之道:规范化 Commit Message 写作指南。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1 commit message 规范

commit message格式都包括三部分:Header,Body和Footer

<type>(<scope>): <subject>

<body>

<footer>

Header是必需的,Body和Footer则可以省略

1.1 Header

  1. 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,通常用于解决因为合并而引入的问题。

  2. Scope(可选)

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

    例如修改了Dao或者Controller,则可以添加表示这些范围受到影响,这有助于更清晰地理解提交的变更影响范围。例如:

    feat(Controller): 添加用户登录功能
    

    这个提交消息中,Controllerscope,表示这次提交影响了控制层。

    fix(DataAccess): 修复数据查询逻辑
    

    这个提交消息中,DataAccessscope,表示这次提交影响了数据访问层。

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

  3. Subject(必需)

    subject是 commit 目的的简短描述,不超过50个字符。规范如下:

    • 以动词开头,使用第一人称现在时,比如change,而不是changedchanges
    • 第一个字母小写
    • 结尾不加句号(.

    例如:

    feat(UserAuth): implement user authentication
    

    这个提交消息中,implement user authenticationsubject,简洁明了地描述了引入用户认证功能的目的。

    fix(Validation): correct input validation logic
    

    这个提交消息中,correct input validation logicsubject,清晰地说明了修复输入验证逻辑的目的。

1.2 Body

Body 部分是对本次 commit 的详细描述,可以分成多行。Body编写有两个注意点。

  1. 使用第一人称现在时,比如使用change而不是changedchanges。这有助于使描述更加直观和连贯,增强可读性。
  2. 应该说明代码变动的动机,以及与以前行为的对比。 Body 部分不仅仅是描述代码的变动,还应该解释为什么进行这个变动,以及与之前的代码行为相比有哪些改进。这有助于其他开发者更好地理解代码变更的背后动机和意图。

1.3 Footer

Footer 部分只用于两种情况。

  1. 不兼容变动

    如果当前代码与上一个版本不兼容,则 Footer 部分以BREAKING CHANGE开头,后面是对变动的描述、以及变动理由和迁移方法。

  2. 关闭 Issue

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

    Closes #234
    

    也可以一次关闭多个 issue 。

    Closes #123, #245, #992
    

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 the
    application. Previously, the validation process was not handling certain edge
    cases correctly, leading to unexpected behavior in specific scenarios.
    
    To resolve this issue, the validation logic has been revised to properly
    handle various input scenarios. This ensures that user input is thoroughly
    validated, 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 and
    reliable 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。

git commit message,闲来无事爱取巧,git,git comit 规范

在这个交互式界面中,你可以选择提交的类型(feat、fix、docs 等)、影响的范围(scope)、简短的描述(subject)以及其他相关信息。通过这种方式,可以确保提交消息符合规范,并提供了更多的上下文信息,便于他人理解变更的目的。

使用 Commitizen 和规范化的提交消息格式,有助于提高代码库的可读性,方便生成自动化的变更日志,并促使开发者更注重写出清晰、明确的提交消息。

2.2 commitlint

commitlint是一个用于检查提交消息是否符合指定规范的工具。它可以帮助团队确保 Git 提交消息的一致性和规范性,尤其是当项目采用类似 Angular Commit Message Conventions 的规范时。

  1. 安装 Commitlint

    首先,你需要安装 commitlint 及其相关的配置和规则。通常,@commitlint/config-conventional 是与 Angular 规范兼容的配置。

    npm install --save-dev @commitlint/config-conventional @commitlint/cli
    
  2. 配置 Commitlint

    在项目根目录下创建 commitlint.config.js 文件,并添加如下内容:

    module.exports = {
      extends: ['@commitlint/config-conventional'],
    };
    

    这个配置文件使用了 @commitlint/config-conventional 中预定义的规则,确保符合常见的提交规范。

  3. 配置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)。

git commit message,闲来无事爱取巧,git,git comit 规范

生成的文档包括以下三个部分。

  • 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.jsonscripts字段。

{
  "scripts": {
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0"
  }
}

以后,直接运行下面的命令即可。

npm run changelog

这个自动化流程不仅简化了 Change log 的生成过程,还确保了记录项目变更的一致性和准确性。生成的文档会按照新特性、bug 修复和重大变更等分类,方便用户快速了解每个版本的变更情况。文章来源地址https://www.toymoban.com/news/detail-772993.html

4 参考资料

  1. 如何规范你的Git commit?—阿里云开发者
  2. Commit message 和 Change log 编写指南—阮一峰的网络日志

到了这里,关于Git Commit 之道:规范化 Commit Message 写作指南的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 数据清洗与规范化详解

    数据处理 流程,也称数据处理管道,是将原始数据转化为有意义的信息和知识的一系列操作步骤。它包括数据 采集 、 清洗 、 转换 、 分析 和 可视化 等环节,旨在提供有用的见解和决策支持。 那我常用的山海鲸可视化软件举例,在数据可视化中数据处理是可视化展示前非

    2024年02月07日
    浏览(46)
  • PyTorch 中的批量规范化

    批量规范化(Batch Normalization)是深度学习中一种常用的技术,用于加速训练过程并提高模型的稳定性和泛化能力。以下是PyTorch中批量规范化的一些关键知识点: 1.nn.BatchNorm1d 和 nn.BatchNorm2d: 2.PyTorch提供了nn.BatchNorm1d用于在全连接层后应用批量规范化,以及nn.BatchNorm2d用于在卷

    2024年01月15日
    浏览(63)
  • 在 Visual Studio 中规范化文件编辑

    生成了对应的 .editorconfig 文件,存放在仓储的根目录。即对整个仓储所有的用 VS 作为 IDE 编辑的项目生效。 同时支持子目录有自己的 .editorconfig 文件,可以选择继承更高级别父目录的配置,也可以不继承。 该文件将应用到模板项目当中。除非特殊情况需根据项目定制编码规

    2024年02月17日
    浏览(46)
  • 【第一章 先导篇】1. 规范化的学习模型

    举例:什么是编码?

    2024年04月25日
    浏览(37)
  • uniapp接口请求api封装,规范化调用

    封装规范和vue中的差不多,都是统一封装成一个request对象,然后在api.js里面调用。 先创建一个utils文件夹,然后里面创建一个request.js,代码如下: 在api文件夹中封装对应的index.js文件,然后导入request对象: 在对应的vue或者react中引入并调用:

    2024年02月08日
    浏览(43)
  • 数据库期末复习(10)数据库规范化理论

     函数依赖(概念):FD 范式分解(评估准则): 模式分解(工具): 如何衡量一个数据库好不好:准确 高效 如果一个数据库设计的不好的话的,会带来哪些问题 删除异常 数据冗余 为什么会导致出现上方的问题:数据依赖 数据依赖的分类:完全依赖,部分依赖,传递依赖和相应的定义 A

    2024年02月08日
    浏览(58)
  • 【数据库原理 • 四】数据库设计和规范化理论

    前言 数据库技术是计算机科学技术中发展最快,应用最广的技术之一,它是专门研究如何科学的组织和存储数据,如何高效地获取和处理数据的技术。它已成为各行各业存储数据、管理信息、共享资源和决策支持的最先进,最常用的技术。 当前互联网+与大数据,一切都建立

    2023年04月12日
    浏览(47)
  • vsCode配置Eslint+Prettier结合使用详细配置步骤,规范化开发

            eslint它规范的是代码偏向语法层面上的风格 。本篇文章以一个基本的vue项目,来说明eslint+prettier+husky配置项目代码规范,为了更好的描述本文,我恢复了vscode的默认设置(即未安装eslint,prettier等插件,setting中也没有相关配置) 1、新建vue3.0脚手架项目 2、项目安装

    2023年04月17日
    浏览(48)
  • 干翻Dubbo系列第十五篇:Rest协议基于SpringBoot的规范化开发

    文章目录 一:Rest协议 1:协议概念 2:协议作用 二:搭建开发环境 1:父项目里边引入的新的版本内容 2:Api中的操作 3:Provider模块 4:Consumer模块 三:编码 1:API模块 2:Provider模块 3:Consumer模块         Rest协议就是我们我们一开始基于SpringBoot或者是SpringMVC开发说的Re

    2024年02月10日
    浏览(53)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包