提交git规范

最新推荐文章于 2025-06-02 20:54:02 发布
最新推荐文章于 2025-06-02 20:54:02 发布
阅读量370 收藏
点赞数 1
CC 4.0 BY-SA版权
分类专栏： git的使用
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_28107929/article/details/90769700

我们提交git的注释规范是：

feat:新增feature
fix: 修复bug，有bug编号要带Bug号
docs: 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等
style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor: 代码重构，没有加新功能或者修复bug
perf: 优化相关，比如提升性能、体验
test: 测试用例，包括单元测试、集成测试等
chore: 改变构建流程、或者增加依赖库、工具等
revert: 回滚到上一个版本

禅道系统上解决Bug的注释规范是：
产生原因：XXX；
解决方案：XXX；
影响范围：XXX
git版本： a3dc059

笔记——Git Commit 提交规范
蜡笔小谢的博客
01-16 5766
在团队协作中，合理的提交规范能够帮助开发者提高代码质量、简化代码审查流程，并促进更高效的团队协作。本文介绍 Git commit 提交规范的重要性，并分享一些最佳实践，帮助开发者更好地管理和记录代码提交。
Git 完整的提交规范教程
余十步的博客
07-06 2238
本文中的关键词 “必须（MUST）”、“禁止（MUST NOT）”、“必要（REQUIRED）”、“应当（SHALL）”、“不应当（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“可以（MAY）” 和 “可选（OPTIONAL）”
git提交日志规范脚本.zip
07-15
项目由于git进行管控，对commit的日志需要进行规范化输出，git的hooks默认管控单仓库，在.git/hooks里面，默认关闭，如果启用的话将后缀.sample去掉。系统提供的commit检验是git文本的最后是否有空格，根据规定，需要进行规则自定义，实现项目提交记录
git的版本
weixin_33860528的博客
10-25 389
type代表某次提交的类型，比如是修复一个bug还是增加一个新的feature。所有的type类型如下：feat： 新增featurefix: 修复bugdocs: 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑refactor: 代码重构，没有加新功能或者修复bugperf: 优化相关，比如提升性...
【Git】提交规范：怎样让你的提交有意义？
2201_75321755的博客
06-02 1132
本文将向你展示一个有意义的提交应该是怎样的！
Git之提交日志规范
xtho62的博客
08-24 3776
1 介绍 Git进行commit时都需要提交说明（commit message）： Git commit -m 'hello world' -m参数就是用来指定commit message的 commit message应该清晰明了，说明本次提交的目的。 2 Commit message的格式 Commit message应该包括三个部分：Header/Body/Footer。其中，Header是必需的，Body和Footer可以省略。 <type>(<scope>): <s
Git 提交代码日志信息
m0_50993351的博客
11-29 1589
一套自己总结的 Git 提交代码日志信息的建议。
git规范与日志规范
禾木人生
08-01 3068
因为要分享git规范,所以今天也顺便做一个总结，这个仅限于对git的开发中和部署时的规范和提交时的日志规范做总结。本文章分两个部分总结git规范，一个是从分支讲解在开发 目录 分支构成 永久分支-master，develop Feature Hotfix 补充（特殊情况下处理方式） git提交规范-commit message Header Type Scope Subject Body...
git-commit-lint-vscode:vscode一款git 规范化提交插件
05-17
这个插件就是规范化git提交规范,让你的提交不仅"好看"还"实用" git 规范提交从何说起? git 规范提交从哪里开始的呢?起源在哪呢?emmmmmm,这就追溯到了Angular了! 让我们看下Angular社区的提交规范 这个提交记录是不是...
Git提交规范
Rsun2018的博客
01-09 1069
revert:”开头，后跟要恢复到的那个提交的标题。然后在消息正文中，应该写上“This reverts commit ”，其中“”是要还原的那个提交的SHA值。正文是对标题的补充，但它不是必须的。和标题一样，它也要求使用祈使句且现在时态，正文应该包含更详细的信息，如代码修改的动机，与修改前的代码对比等。compile、$rootScope、ngHref、ngClick、ngView等，唯一需要注意的是它必须足够简短。代码回滚比较特殊，如果本次提交是为了恢复到之前的某个提交，那提交消息应该以。
Git 提交规范
come from h5
05-22 7177
团队协作，形成良好的代码提交规范。
git日志提交规范
weixin_42077503的博客
06-16 223
Git Commit的日志格式规范
王学森的专栏
07-18 5015
提交规则 一个commit只做一件事情；若一个commit做了多件事情需要拆分成多个commit严格遵循commit message格式每次只允许提交一个commit，若本地有多个commit等待提交，必须等前面的commit合并进入主版本库并在本地合并完成后才可提交后面的commit 内容要求 在commit log中，要写清楚以下几点内容： 这个commit解决了哪个问
Git commit日志基本规范
weixin_30325487的博客
04-05 155
Gitcommit日志基本规范<type>(<scope>):<subject><BLANKLINE><body><BLANKLINE><footer>对格式的说明如下：type代表某次提交的类型，比如是修复一个bug还是增加一个新的feature。所有的type类型如下：feat：新增featuref...
git日志规范
yangbin1265712的专栏
04-10 719
目前可选模块名如下："A2B" "Audio" "BT" "Display" "DP-IN" "DP-OUT" "FAN" "MCU" "OTA" "PD" "PQ" "Thermal" "USB" "WIFI" "OS" "Power" "APP" "Modem" "TBOX" "DDR" "UFS" "EMMC" "Camera" "Sensor" "Security" "IPO" "SCP" "Autotest" "GStreamer" "Net" "Config" "GPS" )
Git 日志规范
qq_41256253的博客
08-19 262
https://zhuanlan.zhihu.com/p/105537435
Git客户端设置全局hooks规范提交日志记录
忆网
12-21 1182
Git客户端设置全局hooks规范提交日志记录 背景： 项目由于git进行管控，对commit的日志需要进行规范化输出，git的hooks默认管控单仓库，在.git/hooks里面，默认关闭，如果启用的话将后缀.sample去掉。系统提供的commit检验是git文本的最后是否有空格，根据规定，需要进行规则自定义，实现项目提交记录如： e.g:(任务号前+t,BUG号前+b) [b1372]解决:… [t1373]增加:… 创建脚本 commit-regulars(正则) [\[【][btBt][0
Git Commit 提交规范，变更日志、版本发布自动化和 Emoji 提交标准
ReturnTmp的博客
03-23 2369
Git Commit 是开发的日常操作, 一个优秀的 Commit Message 不仅有助于他人 Review, 还可以有效的输出 CHANGELOG, 对项目的管理实际至关重要, 但是实际工作中却常常被大家忽略，希望通过本文，能够帮助大家规范 Git Commit，并且展示相关 Commit 工具库或包，及相关变更日志和版本发布自动化工具commitizen git commit 格式化工具, 为我们提供标准化的 commit 信息。帮助我们统一项目 commit ，便于信息的回溯或日志的生成。
git 规范式提交
最新发布
07-25
在 Git 版本控制系统中，提交信息（commit message）是开发者与代码库交互的重要记录。一个规范化的提交信息不仅有助于团队协作，还能提升代码审查效率，并为后续的版本管理和自动化工具提供可靠的数据支持。以下是 Git 提交信息的格式规范与最佳实践。 ### 提交信息的基本格式 Git 提交信息通常遵循如下结构： ``` <type>(<scope>): <subject> <body> <footer> ``` - **`<type>`**：表示提交的类型，如 `feat`（新功能）、`fix`（修复 bug）、`chore`（日常维护）、`docs`（文档更新）等。 - **`<scope>`**（可选）：用于指定提交影响的范围，如模块名或文件名。 - **`<subject>`**：简要描述此次提交的内容，通常不超过 50 个字符。 - **`<body>`**：对提交内容的详细说明，可以包括动机、实现方式、与其他提交的关联等。 - **`<footer>`**：通常用于引用关闭的 issue 或任务编号，如 `Closes #123`。 例如： ``` feat(auth): add password strength meter Implement real-time feedback for password complexity during registration. - Check for uppercase, lowercase, numbers, and special characters - Display visual indicator to user Closes #456 ``` ### 最佳实践 1. **使用 Conventional Commits 规范** Conventional Commits 是一种广泛采用的提交规范，它提供了一套标准化的语义化提交格式，有助于自动生成变更日志（ChangeLog）和进行自动化版本管理[^2]。 2. **保持提交信息简洁明了** 提交信息应尽量简洁，避免冗长。第一行应概括提交目的，后续内容用于补充细节。建议使用祈使句（如 "Fix bug" 而非 "Fixed bug"）[^4]。 3. **每次提交只完成一个逻辑变更** 保持提交的原子性，每个提交应只完成一个清晰的任务。这样可以提高代码审查的效率，并便于回滚或合并。 4. **避免“WIP”或模糊提交信息** 提交信息应具有描述性，避免使用“WIP”、“update”、“changes”等无意义的描述。清晰的提交信息有助于后续查找和理解变更原因。 5. **使用工具辅助规范提交** 可以借助 Git 钩子（Git Hooks）或第三方工具（如 Commitizen、Husky）来强制执行提交规范，防止不规范的提交信息进入代码库。 6. **结合分支策略进行提交管理** 在使用 GitFlow 或 Feature Branch 等分支策略时，确保每个分支的提交信息与该分支的目标一致，便于后续合并和追踪[^3]。 7. **为自动化工具预留结构化信息** 遵循结构化提交格式有助于 CI/CD 系统、自动化测试和版本发布工具解析提交内容，从而生成变更日志或自动升级版本号[^2]。 ### 示例代码：使用 Git Hook 校验提交信息格式 以下是一个简单的 Git Hook 示例，用于检查提交信息是否符合规范： ```bash #!/bin/sh # .git/hooks/commit-msg MSG_FILE=$1 MSG=$(cat $MSG_FILE) # 检查提交信息是否以 feat、fix、chore 等开头 echo "$MSG" | grep -E "^(feat|fix|chore|docs|style|refactor|perf|test|build|ci|revert)" > /dev/null 2>&1 if [ $? -ne 0 ]; then echo "ERROR: Commit message must start with a valid type (feat, fix, chore, etc.)" >&2 exit 1 fi # 检查第一行长度是否超过50字符 FIRST_LINE=$(echo "$MSG" | head -n 1) if [ ${#FIRST_LINE} -gt 50 ]; then echo "ERROR: First line of commit message must be <= 50 characters" >&2 exit 1 fi exit 0 ``` ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值