git 提交规范

已于 2022-08-25 16:50:12 修改
阅读量791 收藏 1
点赞数 1
分类专栏： 知识碎片 文章标签： git github angular.js
于 2022-08-25 16:49:51 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43287892/article/details/126527608
版权

Git 提交规范

Git 提交格式

目前市面上认可度较高的是 Angular 规范，使用此规范来对 git commit message 进行限制。
每次提交，commit message 都包含三个部分：header、body、footer。用空行隔开。

<type>(<scope>): <subject>
空一行
<Body>
空一行
<Footer>

其中 header是必须的， body 和 footer 可以省略
不管是哪一个部分，任何一行都不得超过72个字符。这是为了避免自动换行影响美观。


Header

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

type

type用于说明 commit 的类别，只允许使用下面标识。
常见type

scope

非必填，scope用于说明 commit 影响的范围，建议填写影响的功能模块。

subject

必填， commit 目的的简短描述，英文建议不超过50个字符，中文建议不超过24个字
● 建议使用中文
● 结尾不加句号或其他标点符号

Body

Body 部分是对本次 commit 的详细描述，可以分成多行。
● 使用第一人称现在时，比如使用change而不是changed或changes。
● 应该说明代码变动的动机，以及与以前行为的对比。

Footer

Footer 部分只用于两种情况：不兼容变动和关闭 Issue。详见Commit message 和 Change log 编写指南

Git 提交工具

文字说明略，详见 Git Commit规范

Git 提交频率

其实如果严格按照提交格式去写说明后，提交频率也基本上可以确定下来。一次提交里，代码都具有相关性。如果无相关性的代码，需要放到多次提交里。涉及到同一个文件被两个待提交都有修改的，建议先针对一次提交修改该文件，待提交后，再进行二次提交的修改。一定要注意拆分。


分支的艺术

一个中心版本库（我们叫它 origin）至少包括两个分支，即主分支（master）和开发分支（develop）
在一个团队开发协作中，建议要有辅助分支的概念。
辅助分支的最大特点就是生命周期十分有限，完成使命后即可被清除。
辅助分支大体包括如下几类：管理功能开发的分支、帮助构建可发布代码的分支、可以便捷的修复发布版本关键 BUG 的分支等等。
设置三类辅助分支，我们称之为 Feature branches、Release branches、Hotfix branches。
至此，形成了如下这张最重要的组织组，包含了两个粗体字分支（master/develop）和三个细体字分支（feature/release/hotfixes）
分支的艺术
详细参考 《GIT分支管理是一门艺术》


引用资料：
Commit message 和 Change log 编写指南
git commit 使用及规范
如何规范你的Git commit？
IDEA插件-Git Commit Template
Git commit规范
GIT分支管理是一门艺术





图片

imautumn
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
git提交规范
litterboys的博客
03-23 8822
遵循 Git 提交规范可以让团队协作更加高效和规范，也更容易进行版本管理和代码维护。希望大家都能养成良好的提交习惯！
git提交规则及报错
紫冰的博客
03-17 3183
报错subject may not be empty [subject-empty]type may not be empty [type-empty]git commit规范 subject may not be empty [subject-empty] type may not be empty [type-empty] ✖ 主题不能为空[主题为空] ✖ 类型不能为空[类型为空] git commit 又一定规范，需要按照规范来提交 在git commit -m “” 时，要使用 type: xxxx
Git 提交规范
最新发布
come from h5
05-22 1028
团队协作，形成良好的代码提交规范。
Git 学习笔记——git 提交规范和 Github/Gitee 使用说明
un357951的博客
01-24 510
我们以vscode项目进行介绍访问https://github.com/microsoft/vscode 即可看到如下的界面页面的左上角：Star所以尽量不要像朋友圈集赞一样要求身边朋友刷starFork：Fork操作实际上是创建一个仓库的副本，并将仓库的upstream指向原仓库小问题：为什么要fork呢？为什么不直接push呢？fork方便了多人协作Watch：Watch操作可以向你的邮箱中推送该仓库的推送信息提示：如果不是特别重要的项目，不要随意点Watch，否则很容易邮箱被轰炸。
Git上传文件不能超过100M 解决方案
多分享一点点，共同进步一点点
03-15 5220
此命令的目的是设置最大文件上限改为 500M (52428000=500×1024×1024,即500M)上传项目到Git上，当某个文件大小超过100M时，就会上传失败，因为默认的限制了上传文件大小。如果需要上传超过100M的文件，就需要我们自己去修改配置。之前git中的配置是没有这一项的,执行完以上语句后输入。可以看到配置项的最下面多出了一行我们刚刚配置的内容。此时，可以重新上传提交仓库文件了。，进入项目所在的文件夹；
使用 commitizen 规范 Git 提交说明
关注我！带你一路 "狂飙" 到底！
08-18 771
在工作中一份清晰简介规范的 Commit Message 能让后续代码审查、信息查找、版本回退都更加高效可靠。Git 每次提交代码时，都需要写 Commit Message (提交说明)，否则就不允许提交。Commitizen 是一个撰写符合上面 Commit Message 标准的一款工具。3. 这时就可以全局使用 git cz 命令来代替 git commit 命令了。2. 配置，打开项目的 package.json 文件，配置如下。用于说明影响的范围，比如数据层、控制层、视图层等等。
Git提交规范结合实践
04-11
Git提交规范是软件开发团队协作中的重要组成部分，它有助于保持代码历史清晰，便于代码审查，回溯更改，以及自动化发布流程。以下是对标题和描述中所述知识点的详细说明： 1. **提交过程规范**： - **初始提交**：...
git-commit-lint-vscode:vscode一款git 规范化提交插件
05-17
这个插件就是规范化git提交规范,让你的提交不仅"好看"还"实用" git 规范提交从何说起? git 规范提交从哪里开始的呢?起源在哪呢?emmmmmm,这就追溯到了Angular了! 让我们看下Angular社区的提交规范 这个提交记录是不是...
git提交代码常用规范
12-30
git提交代码常用规范
git提交代码注释规范
01-12
git提交代码注释规范、git提交常用操作的规范指南、[A] 新增 ：(新加入的需求) [M] 修改 ：( 修改或者重构代码) [D] 删除 ：(删除多余的文件 ) [F] 修复 ：(修复bug)
git提交日志规范脚本.zip
07-15
项目由于git进行管控，对commit的日志需要进行规范化输出，git的hooks默认管控单仓库，在.git/hooks里面，默认关闭，如果启用的话将后缀.sample去掉。系统提供的commit检验是git文本的最后是否有空格，根据规定，...
git commit 规范化信息提交工具
阿然的专栏
12-10 1769
灵感来源于这篇文章 1. 标准化 commit message 规范且有意义的提交记录，有助于追踪代码修改和查看历史记录 现在支持以下九种类型（参考 Angular 规范的 commit message） feat： 新功能（feature） fix： 修补bug docs： 文档（documentation） style： 格式（不影响代码运行的变动） refactor： 重构（即...
Git提交信息格式
朱工的专栏
11-23 5144
什么情况需要提交 每当完成了一个新功能、修复了一个错误、重构一个模块或者调整格式时，都应该提交一次代码，以便版本工具记录这次修改。 规定：不能将不相关的修改一块提交，混合不同的功能会使得以后的问题查找或者其他成员浏览历史变得困难。 提交信息格式 <type>: <subject> //空一行 <body> type：用于说明本次提交的类别，规定为以下几种： feat：新功能 fix：修复错误 refactor：重构代码 style：调整代码格式（不影响代码运行
Git基础 - 查看提交历史，限制输出长度，撤销
wwjwyb的专栏
09-17 593
Git基础查看提交历史 限制输出长度 撤销操作 取消暂存的文件 撤销对文件的修改
git提交代码的基本操作及避坑指南
harXX的博客
11-02 1247
基本使用 1.初始化一个本地仓库（第一次提交需要初始化）： git init 2.将README.md文件添加到缓存（第一次需要添加该文件） git add README.md 3.将文件添加到缓存(.代表所有文件) git add . 4.提交缓存中的代码至本地仓库 git commit -m "本次提交的相关描述" 5.关联远程仓库（第一次需要关联，后期只需要直接提交） git remote add origin 远程仓库地址 6.提交 本地仓库 的代码至 远程仓库master分支 下 git
Git提交规范指南
大河之犬的博客
03-14 909
如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。表示commit的作用范围，如数据层、视图层，也可以是目录名称。如果当前 commit 用于撤销以前的 commit，则必须以。，其中的hash是被撤销 commit 的 SHA 标识符。开头，后面跟着被撤销 Commit 的 Header。Body部分的格式是固定的，必须写成。
git代码提交规范
weixin_42219478的博客
11-05 4886
一、提交格式 type （scope）: message 二、参数介绍： 1、type：指的代码的提交类型，不同的提交类型表示对应不同的代码改动，比如： feat：新功能的开发 fix：bug的修复 docs：文档格式的改动 style：代码格式改变 refactor：对已有的功能进行重构 perf：性能优化 test：增加测试 build：改变了build工具 revert：撤销上一次的commit提交 chore：构建过程或辅助工具的变动 2、scope：用于说明commit影响的范围，比如：权限模块、
Git提交规范
weixin_43905464的博客
10-21 328
文章目录前言一、Git版本规范1.分支2.Tag3.提交规范总结 前言 统一团队Git Commit标准，便于后续代码review、版本发布、自动化生成change log； 可以提供更多更有效的历史信息，方便快速预览以及配合cherry-pick快速合并代码； 团队其他成员进行类git blame时可以快速明白代码用意； 一、Git版本规范 1.分支 master分支为主分支(保护分支)，不能直接在master上进行修改代码和提交 develop分支为测试分支，所以开发完成需要提交测试的功能合并
git commit 提交规范 & 规范校验
热门推荐
BiuBiu_Tian(田)
06-06 7万+
1、背景 在多人协作项目中，如果代码风格统一、代码提交信息的说明准确，那么在后期协作以及Bug处理时会更加方便。 因此，在本文章中，我会介绍怎么使用下面这个工具，在git push 代码之前检测commit messages： commitlint husky commitlint介绍 2、先来介绍博主采用的commit规范 Commit message格式 &amp;lt;ty...
怎么限制git提交规范
07-12
要限制Git提交规范，可以采取以下几个方法： 1. 使用Git钩子（Git hooks）：Git钩子是在特定Git事件发生时自动触发的脚本。你可以在本地或者远程仓库中设置Git钩子来验证提交信息的规范性。比如，在`pre-commit`钩子中可以编写脚本，检查提交的消息是否符合规范，如果不符合规范则阻止提交。 2. 使用Git提交模板（Git commit template）：你可以创建一个提交模板文件，定义提交信息的格式和规范，并将其配置为Git的默认提交模板。这样，在每次提交时，Git会自动打开该模板文件供你填写提交信息。你可以在模板文件中添加规范说明，以引导开发者按照规范填写信息。 3. 使用代码审查工具：一些代码审查工具（例如，Gerrit、Phabricator等）提供了对提交信息进行验证的功能。你可以配置这些工具来检查提交信息是否符合规范，并在不符合规范时拒绝合并。 4. 培训团队成员：进行团队内部的培训，提醒团队成员遵守提交规范，并说明为什么提交规范对于项目的质量和协作至关重要。 无论采取哪种方式，都应该明确规范的要求，并与团队成员进行充分的沟通和培训，以确保规范的有效实施。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值