Git 提交规范【记录】

原创 已于 2023-04-12 18:05:14 修改 · 275 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#git #github

于 2023-03-21 10:32:15 首次发布
GitCommit规范定义了在提交代码时使用的不同类型，如新增功能(feat)、修复bug(fix)、文档更新(docs)、重构(refactor)等，旨在提高代码管理和协作效率。

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

以下是commit提交规范，主要是在提交代码时标识本次提交的属性

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
chore：构建过程或辅助工具的变动
revert：撤销，版本回退
perf：性能优化
test：测试
improvement：改进
build：打包
ci：持续集成
笔记——Git Commit 提交规范
蜡笔小谢的博客
01-16 5891
在团队协作中，合理的提交规范能够帮助开发者提高代码质量、简化代码审查流程，并促进更高效的团队协作。本文介绍 Git commit 提交规范的重要性，并分享一些最佳实践，帮助开发者更好地管理和记录代码提交。
git 提交规范，feat、fix、chore、docs、style是什么意思!
2401_89806660的博客
07-11 520
使用规范的提交消息可以让项目更加模块化、易于维护和理解，同时也便于自动化工具（如发布工具或 Changelog 生成器）解析和处理提交记录。通过编写符合规范的提交消息，可以让团队和协作者更好地理解项目的变更历史和版本控制，从而提高代码维护效率和质量。
代码提交日志规范
weixin_30394981的博客
07-25 413
规范说明： 关键字用[]括起来 关键字和标题之间用一个空格 标题不要使用句号结尾 标题不超过50个字符。 正文与标题另外起换行。 正文解释是什么和为什么，而不是如何做。 关键字： [add] 新增 [update] 修改 [delete] 删除 [fix] 修复 [doc] 文档 [style] 格式 [refactor] 重构 [test] 增加测试 [tool] 工具相关...
代码提交规范
rbgg_mp的博客
04-22 399
代码提交规范 大量的代码提交，必然会产生大量的 Commit log. 每一条都 Commit log 记录着某一阶段所完成的事以及关注点，应该尽可能详细具体；在工作中一份清晰规范的 Commit Message 能让后续代码审查、信息查找、版本回退都更加高效可靠 提交格式 <type>: <subject> 注意冒号后面有空格。 type 用于说明 commit 的类别，只允许使用下面 7 个标识。 feat：新功能（feature） fix：修补 bug docs：
规范系列之代码提交日志
极简
06-30 460
代码提交规范
代码提交规范和技巧
wade1010的专栏
11-03 507
已经提交的三次提交合并，这个时候可以使用 git rebase -i 来合并这3个提交信息，经过rebase之后，提交信息变成这样。1、我们代码已经commit，但是我们发现少提交一个文件，大部分人都是再commit一次，然后提交信息写"补充提交"，这种提交其实是没有意义的 ，因为是大意导致无效提交的产生，这个时候可以使用git commit --amend。3、把一个分支的代码提交信息合并到另外一个分支里面，这个时候就有一个命令 git cheeey-pick。
【软件开发规范篇】Git代码提交规范
分享是一种境界，勤于分享，乐于分享！
04-28 4532
本文介绍软件项目开发过程中，代码提交到git仓库，建议遵循的一些规范。每次提交代码到 Git 仓库时，都需要写 commit message。通常情况下，commit message 应该清晰明了，说明本次提交的目的和具体操作等。然而，在日常开发中，开发者们提交的 commit message 千差万别，中英文混用，导致后续代码维护成本很高，有时候甚至自己都不知道修复的是什么问题。因此，为了解决这些问题，建议大家在提交代码的时候，能遵循一些规范或约定，从而提高代码规范，提高开发效率。
Git 完整的提交规范教程
余十步的博客
07-06 2279
本文中的关键词 “必须（MUST）”、“禁止（MUST NOT）”、“必要（REQUIRED）”、“应当（SHALL）”、“不应当（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“可以（MAY）” 和 “可选（OPTIONAL）”
Git提交规范结合实践
04-11
Git提交规范是软件开发团队协作中的重要组成部分，它有助于保持代码历史清晰，便于代码审查，回溯更改，以及自动化发布流程。以下是对标题和描述中所述知识点的详细说明： 1. **提交过程规范**： - **初始提交**：...
git-commit-lint-vscode:vscode一款git 规范化提交插件
05-17
这个插件就是规范化git提交规范,让你的提交不仅"好看"还"实用" git 规范提交从何说起? git 规范提交从哪里开始的呢?起源在哪呢?emmmmmm,这就追溯到了Angular了! 让我们看下Angular社区的提交规范 这个提交记录是不是...
Git代码提交信息规范
卓越之识论道，平常之识论事，狭隘之识论人
10-23 1638
git提交代码信息规范
【规范】看看人家Git提交描述，那叫一个规矩
JavaDog程序狗
03-08 2073
1.IDEA Git描述规范插件:git commit message helper 2.Git提交描述格式规范,type、scope、subject、body、footer内容分析 3.实例Git提交描述解析:新功能提交、bug修复、文档提交
3.git commit 代码提交规范
weixin_51614564的博客
07-17 2015
2.我们现在主要目的是让我们的代码提交信息尽可能的规范，通常我们的gitcommit会按照统一风格来提交，这样可以快速定位每次提交的内容，方便之后进行版本控制。1.通常我们提交代码是这样提交的的，如下面例子这样，这样的习惯是很不好的,我们最好是当前做了了什么操作，修改哪些东西备注说明。如果我们按照cz来规范了提交代码风格，但是依然有同事通过gitcommit按照不规范的格式提交应该怎么办呢？第三步选择提交的信息（给本次提交写上对应的描述）第五步这次提交是不是一次的大的更新。...
git commit 代码提交规范
辰风沐阳
08-08 2384
每个人 git 的提交记录都有自己的风格和习惯，特别是多人协作开发的项目，如果没有一套完整的规范，则每个人的代码提交描述内容会很随意，质量参差不齐，会降低 log 的可读性和维护性。所以，需要有一套 git 提交规范，使得提交记录清晰明了，让人一看就能知道每次提交的目的。本文记录一种业界比较认可和常用的规范，来自 AngularJS 团队规范。...
git代码提交规范
weixin_42219478的博客
11-05 5046
一、提交格式 type （scope）: message 二、参数介绍： 1、type：指的代码的提交类型，不同的提交类型表示对应不同的代码改动，比如： feat：新功能的开发 fix：bug的修复 docs：文档格式的改动 style：代码格式改变 refactor：对已有的功能进行重构 perf：性能优化 test：增加测试 build：改变了build工具 revert：撤销上一次的commit提交 chore：构建过程或辅助工具的变动 2、scope：用于说明commit影响的范围，比如：权限模块、
代码提交日志规范化
沸腾了的博客
03-28 1292
操作类型[模块/功能] 具体描述例如： fix[日志]修改一个导致日志输出错误的问问题。
[特殊字符] 潜入深渊：探索 Linux 内核源码的奇幻之旅与生存指南
最新发布
kernelguru的博客
08-22 820
Linux内核源码探索指南 Linux内核源码是驱动数字世界的核心工程杰作，全球开发者协作的典范。关键目录包括：arch/（CPU架构相关）、drivers/（硬件驱动）、fs/（文件系统）、kernel/（进程调度等核心功能）。建议开发者通过具体问题切入（如系统调用流程），善用cscope/ctags等工具，结合官方文档逐步深入。内核开发采用邮件列表协作模式，补丁需经严格审查。初学者应注重理解主线逻辑，从简单驱动开始实践，警惕并发问题。探索内核源码是理解计算机系统本质的绝佳途径，虽具挑战但收获巨大。
git提交规范
03-08
### Git 提交信息最佳实践 #### 遵循清晰的历史记录原则 Git 日志命令允许查看提交历史，这对于理解项目的发展过程至关重要[^1]。因此，在编写提交信息时应确保其能够帮助团队成员快速理解每次更改的目的和范围。 #### 使用结构化的提交消息格式 推荐遵循 Angular 团队提出的标准化 Commit Message 格式： ```text <type>(<scope>): <subject> <body> <footer> ``` 其中各部分含义如下： - `<type>` 描述此次变更的性质（如 `feat` 表示新功能；`fix` 表示修复错误） - `<scope>` 可选参数，用于指定受修改影响的部分或模块名称 - `<subject>` 简短概括本次改动的核心内容 - `<body>` 和 `<footer>` 是可选项，分别用来提供更详细的解释以及关联问题编号等附加信息 这种格式有助于提高代码库维护效率并促进协作交流。 #### 结合工具强制执行规范 为了避免不合规的消息被提交到仓库中，可以利用 husky 工具配合 commitlint 来实现自动化校验机制[^3]。具体来说就是设置 pre-commit hook 或 prepare-commit-msg hook ，从而在实际创建提交之前先检查即将使用的 Commit Message 是否满足预定义的标准模式。 对于那些确实有必要绕过某些特定规则的情况，则可以通过添加 Java 注解的方式临时禁用相应的静态分析警告[^4]。不过这种方式应当谨慎使用，并尽可能保持例外情况的数量最少化。 #### 示例：标准的 Git 提交信息 假设在一个 Web 应用程序开发过程中实现了新的用户认证特性，那么对应的提交信息可能是这样的形式： ```text feat(auth): add OAuth login support for third-party services Implement Google and Facebook authentication flows as part of our ongoing effort to enhance user experience. This change includes updates to both frontend UI components and backend API endpoints. Resolves #1234 ``` 上述例子不仅指明了具体的改进措施及其背景原因，还提到了所解决的任务号以便追踪进度。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

你好像很好吃a

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值