git commit 提交规范

最新推荐文章于 2025-03-18 15:49:11 发布
最新推荐文章于 2025-03-18 15:49:11 发布
阅读量1.7k 收藏 25
点赞数 27
文章标签： git java 开发语言 代码规范
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_47885323/article/details/135473711
版权
本文介绍了Git提交时应遵循的ConventionalCommits约定，包括commit的类型（如feat、fix、refactor等）、作用域、描述、BREAKINGCHANGE处理以及不同类型的示例。这些规范有助于团队更好地理解和跟踪代码更改历史。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

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

<body>

<footer>

大致分为三个部分(使用空行分割):

  1. 标题行: 描述主要修改类型和内容
  2. 主题内容
  3. 页脚注释: 放 Breaking Changes 或 Closed Issues

type

commit 的类型：

  • feat: 新功能、新特性
  • fix: 修改 bug
  • perf: 更改代码，以提高性能（在不影响代码内部行为的前提下，对程序性能进行优化）
  • refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
  • docs: 文档修改
  • style: 代码格式修改, 注意不是 css 修改（例如分号修改）
  • test: 测试用例新增、修改
  • build: 影响项目构建或依赖项修改
  • revert: 恢复上一次提交
  • ci: 持续集成相关文件修改
  • chore: 其他修改（不在上述类型中的修改）
  • release: 发布新版本
  • workflow: 工作流相关文件修改

scope

commit 影响的范围, 比如: route, component, utils, build...

subject

commit 的概述

body

commit 具体修改内容, 可以分为多行.

footer

一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.

约定式提交规范

以下内容来源于：https://www.conventionalcommits.org/zh-hans/v1.0.0-beta.4/

  • 每个提交都必须使用类型字段前缀，它由一个名词组成，诸如 feat 或 fix ，其后接一个可选的作用域字段，以及一个必要的冒号（英文半角）和空格。
  • 当一个提交为应用或类库实现了新特性时，必须使用 feat 类型。
  • 当一个提交为应用修复了 bug 时，必须使用 fix 类型。
  • 作用域字段可以跟随在类型字段后面。作用域必须是一个描述某部分代码的名词，并用圆括号包围，例如： fix(parser):
  • 描述字段必须紧接在类型/作用域前缀的空格之后。描述指的是对代码变更的简短总结，例如： fix: array parsing issue when multiple spaces were contained in string.
  • 在简短描述之后，可以编写更长的提交正文，为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
  • 在正文结束的一个空行之后，可以编写一行或多行脚注。脚注必须包含关于提交的元信息，例如：关联的合并请求、Reviewer、破坏性变更，每条元信息一行。
  • 破坏性变更必须标示在正文区域最开始处，或脚注区域中某一行的开始。一个破坏性变更必须包含大写的文本 BREAKING CHANGE，后面紧跟冒号和空格。
  • 在 BREAKING CHANGE: 之后必须提供描述，以描述对 API 的变更。例如： BREAKING CHANGE: environment variables now take precedence over config files.
  • 在提交说明中，可以使用 feat 和 fix 之外的类型。
  • 工具的实现必须不区分大小写地解析构成约定式提交的信息单元，只有 BREAKING CHANGE 必须是大写的。
  • 可以在类型/作用域前缀之后，: 之前，附加 ! 字符，以进一步提醒注意破坏性变更。当有 ! 前缀时，正文或脚注内必须包含 BREAKING CHANGE: description

示例

fix

如果修复的这个BUG只影响当前修改的文件，可不加范围。如果影响的范围比较大，要加上范围描述。

例如这次 BUG 修复影响到全局，可以加个 global。如果影响的是某个目录或某个功能，可以加上该目录的路径，或者对应的功能名称。

// 示例1
fix(global):修复checkbox不能复选的问题
// 示例2 下面圆括号里的 common 为通用管理的名称
fix(common): 修复字体过小的BUG，将通用管理下所有页面的默认字体大小修改为 14px
// 示例3
fix: value.length -> values.length

feat

feat: 添加网站主页静态页面

这是一个示例，假设对点检任务静态页面进行了一些描述。
 
这里是备注，可以是放BUG链接或者一些重要性的东西。

chore

chore 的中文翻译为日常事务、例行工作，顾名思义，即不在其他 commit 类型中的修改，都可以用 chore 表示。

chore: 将表格中的查看详情改为详情
KA航少
关注
Git Commit提交规范总结
拾年一剑 的专栏
02-27 6838
团队协作中，规范的Git提交记录，使提交历史明确可追溯，有助于更好的协作，方便后期代码的开发和维护
git commit 规范指南
weixin_34375233的博客
04-13 1187
前言 Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。但是，一般来说，commit message 应该清晰明了，说明本次提交的目的。 不过话说回来，作为最具个人创造力和最会利用工具的物种——程序猿，最好是能有规范和工具的约束。否者的话，你可能看到以下的commit message： 目前，社区...
代码工程必备能力—Commit 规范
benjaminparker的博客
10-24 6313
Git是目前应用最为广泛的开源分布式版本控制系统，不论是对企业团队还是科研任务都需要掌握使用Git的技巧，文章重点在于总结如何使用Git的一些功能，包括讲述的文章、资源和个人的想法。 Git 官方网址：Git 一. Git Commit 的作用（干啥用的） Git Commit：指的是提交说明，用于标注此次修改的内容以及需要提示的信息,官方给出的解释是：Record changes to the repository（记录添加到仓库当中的修改）。 提供一个场景来做...
【git】git管理规范--分支命名规范、CommitMessage规范
最新发布
lillianqdzpw
03-18 1444
Subject（主题）：简洁描述提交的目的，不超过 50 个字符。Scope（范围）：说明提交的影响范围（可选）。功能分支（Feature）示例 2：修复 bug。
git commit 规范
greed
05-22 4387
一个 commit message 由三部分构成： 标题行: 必填, 描述主要修改类型和内容 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等 页脚注释: 放 Breaking Changes 或 Closed Issues 在这三部分中，<>中的内容分别表示： type: commit 的类型 feat: 新特性 fix: 修改问题 refactor: 代码重构 docs: 文档修改 style: 代码格式修改, 注意不是 css 修改 test: 测试用例修改 chore
git commit提交规范
axzzy的博客
11-03 2833
📈 (上升趋势图) :chart_with_upwards_trend : 添加分析或跟踪代码。🏁 (旗帜) :checkered_flag : 修复 Windows 下的问题。🌐 (地球) :globe_with_meridians : 国际化与本地化。✅ (白色复选框) :white_check_mark : 增加测试。💚 (绿心) :green_heart : 修复 CI 构建问题。🐧 (企鹅) :penguin : 修复 Linux 下的问题。🔒 (锁) :lock : 修复安全问题。
Git Commit 规范
weixin_44273311的博客
06-26 1087
git commit 规范
笔记——Git Commit 提交规范
蜡笔小谢的博客
01-16 4858
在团队协作中，合理的提交规范能够帮助开发者提高代码质量、简化代码审查流程，并促进更高效的团队协作。本文介绍 Git commit 提交规范的重要性，并分享一些最佳实践，帮助开发者更好地管理和记录代码提交。
常用的Git commit 提交规范！
嵌入式大杂烩
07-04 1196
在我们嵌入式开发中，版本管理工具Git已经成为不可或缺的一部分。Git帮助我们记录代码变更历史，提供了强大的代码协作开发功能。初学时，我们基本都是按照下面的格式这么来写commit信息的吧？甚至有些公司的commit信息也很随意也类似于上面这样的。这样的commit信息包含的信息比较有限，不利于后续的版本追溯。其实，为了确保团队成员能够更高效地协作，并且保持代码库的整洁和有序，需要团队各成员遵循达成一致的commit提交规范。
Git Commit提交规范和IDEA插件Git Commit Template的使用
热门推荐
noaman_wgs的博客
12-06 1万+
Git是最牛逼的开源分布式版本控制系统，日常开发中常用来管理代码提交、恢复、追踪，是团队开发最常用的一个代码管理工具。 在我们修改了代码并且提交之前，常会使用git commit -m 'change'命令来描述我们代码改动的内容，但是很多都不规范，随处可见的 git commit -m 'update'，以致于不能清晰地知道每次提交代码的变更内容，所以需要一种规范来管理代码提交的内容。 一、Gi...
【知识整理】Git Commit Message 规范
李木
02-23 2994
前面咱们整理过Code Review 一文，提到了 Review 的重要性，已经同过gitlab进行CodeReview 的方式，那么本文详细说明一下对CodeReivew非常重要的Git Commit Message 规范。我们在每次提交代码时，都需要编写 Commit Message，否则是不允许提交的。书写好的 Commit Message 能大大提高代码维护的效率。避免开发人员在项目中群魔乱舞，搞得代码一团糟，搞的项目就被糟践了。且开发日后的维护，都将是灾难。
git commit规范提交
酒无忧的博客
11-06 1795
Git每次提交代码时，都要写Commit Message（提交说明），通常情况下，Commit Message应该清晰明了，说明本次提交的目的和具体操作等。例如，有些人会写此次代码的修改是基于哪个模块，有些人会写解决了哪些Bug，有些则只写修改了哪个文件，中英文混用等等五花八门的Commit格式，这导致后续的代码维护成本很高，有时候提交人看Commit Message都不知道自己改了什么。比如查阅某个业务的修改历史，查阅某个时间段修复了哪些Bug，因为Commit没有统一的格式，就比较难快速获取这些信息。
git commit规范
weixin_51474815的博客
01-23 8145
如何规范git commit提交 github是我们用于协同开发的平台，方便开发人员协同开发，极大提高了开发效率，但是经过团队第一次协同开发后，我们发现了一个很大的问题，我们的git commit非常不规范，至于在开发后期项目出现bug之后，很难找到问题所在，为了规范以后的开发，学习使用commitizen,husky以及standard-version来规返回git commit提交，并且自动化生成CHANGLOG commitizen commitizen是用来制定git commit规范的工具 首先让
Git使用——commit规范
Joseph的博客
03-10 2637
一、制定目的 统一团队Git commit日志标准，便于代码review，版本发布以及日志自动化生成等。 统一团队的Git工作流，包括分支使用、tag规范、issue等 二、Git工作流 分支规范 分支类型 命名规范 创建自 合并到 说明 master master – – 长期分支，部署到生产环境中的代码 develop develop – master 长期分支，进行代码集成的分支 feature feature/* develop develop 短期分支，新功能分支
Git—commit规范
m0_73555097的博客
09-02 923
使用git多人开发时，如果不使用统一的规范则会导致每次更新的内容描述千差万别，不利于多人协作，所以尽量规范commit写法，使内容提交清晰明了。
Git commit 规范
路漫漫其修远兮，吾将上下而求索！
07-26 2812
在多人协作项目中，良好的 commit 风格如下所示 这里使用的工具是 commitlint。 1 Commitlint message 的格式 Commitlint 基于 Angular 的规范。很多工具也是基于此规范, 它的 message 格式如下: // Header &lt;type&gt;(scope): &lt;subject&gt; // 空一行 Body // 空一行...
git commit 提交规范举例
02-13
### Git Commit Message 规范示例 #### 单行提交信息格式 每次提交应当只解决一个问题，这有助于简化代码审查过程并提高可追溯性。单行提交信息应该简洁明了，通常不超过72个字符[^1]。 ```plaintext type(scope): subject ``` - `type` 表示更改的性质（如 feat, fix） - `scope` 是可选字段，用于指定受影响的部分或模块名称 - `subject` 描述所做的改动摘要 #### 完整多行提交信息结构 对于更复杂的变更，则推荐采用如下完整的多行格式： ```plaintext type(scope): subject Body explaining the change and its motivation. Footer with any relevant issue references. ``` 其中： - **Header**: 包含三部分——类型(type)，作用域(scope)以及主题(subject) - **Body**: 对修改原因及实现细节做进一步解释说明；如果适用的话还可以提及如何测试这些变化。 - **Footer**: 如果有的话，在这里注明关联的问题编号或者其他元数据信息，例如关闭某个GitHub Issues。 #### 实际案例展示 ##### 添加新功能的例子 当向项目中引入新的特性时，可以这样书写commit message: ```plaintext feat(user-profile): add avatar upload feature Allow users to upload avatars from their local machines or via URL links. This enhancement improves user experience by personalizing profiles. Closes #1234 ``` ##### 修复Bug的例子 针对错误修正类别的提交消息则像下面这样表达: ```plaintext fix(authentication): resolve login redirect loop on Safari browser The previous implementation caused an infinite redirection when logging in using Safari due to incorrect handling of session cookies. The solution was implemented according to best practices outlined at MDN Web Docs regarding secure cookie settings. Fixes #9876 ``` #### 工具支持 为了确保团队成员都能遵循一致的消息格式化规则，建议使用工具辅助验证。例如可以通过配置 pre-commit hook 来运行 validate-commit-msg 或者集成 CI/CD 流程中的检查脚本以自动拒绝不符合规定的提交请求[^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值