Git 注释规范

git提交注释规范插件 1、前言 为什么要注重代码提交规范? 在团队协作开发时,每个人提交代码时都会写 commit message。 每个人都有自己的书写风格,翻看我们组的git log, 可以说是五花八门,十分不利于阅读和维护。 一般项目开发都是多分支共存,master、develop、feature、hotfix、release等分支,在这么多分支中,我们会有一个稳定的master分支,但是我们需要将分支代码进行merge。存在规范的commit message可以帮助我们很轻松的合并代码以及发现问题。例如使用Jenkins 阅读详情

提交格式:

<type>(<scope>): <subject>
// 空一行
<body>

范例:

fix #251: add DataValidation

提交的具体情况

 说明:

type(必需)

用于说明 commit 的类别

  • br: 此项特别针对bug号,用于向测试反馈bug列表的bug修改情况
  • feat:新功能(feature)
  • fix:修补
  • docs:文档(documentation)
  • style: 格式(不影响代码运行的变动)
  • refactor:重构(即不是新增功能,也不是修改bug的代码变动)
  • test:增加测试
  • chore:其他的小改动. 一般为仅仅一两行的改动, 或者连续几次提交的小改动属于这种
  • revert:feat(pencil): add 'graphiteWidth' option (撤销之前的commit)
  • upgrade:升级改造
  • bugfix:修补bug
  • optimize:优化
  • perf: Performance的缩写, 提升代码性能
  • test:新增测试用例或是更新现有测试
  • ci:主要目的是修改项目继续完成集成流程(例如Travis,Jenkins,GitLab CI,Circle)的提交
  • build: 主要目的是修改项目构建系统(例如glup,webpack,rollup的配置等)的提交

scope(可选)

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

subject(必需)

subject是 commit 目的的简短描述,不超过50个字符。
以动词开头,使用第一人称现在时,比如change,而不是changed或changes
第一个字母小写
结尾不加句号(.)

<body>(可选)

部分是对本次 commit 的详细描述,可以分成多行

 

优化自:https://www.jianshu.com/p/79454cf00945

Git Commit message 编写指南: https://gitee.com/help/articles/4231#article-header0

git提交多行注释 git commit -m 如何多行注释? 阅读详情

相关推荐

软件工程领域Git的代码注释规范

在现代软件开发中,Git已成为事实上的版本控制标准。随着项目规模和团队复杂度的增加,良好的代码注释规范对于维护代码质量和团队协作效率至关重要。系统阐述Git环境下的代码注释规范体系提供可立即实施的实践指南分析注释规范对软件工程各环节的影响推荐相关工具和工作流优化方案本文涵盖从个人开发到企业级项目的各种规模应用场景,适用于传统单体架构和现代微服务架构。本文首先介绍Git注释规范的基础概念,然后深入解析主流规范标准。核心部分将展示具体实施方法和工具支持,最后探讨实际应用场景和未来趋势。

软件工程实践的博客 662

Git 代码提交注释管理规范

大致分为三个部分(使用空行分割): 1. 标题行: 必填, 描述主要修改类型和内容 2. 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等 3. 页脚注释: 放 BreakingChanges或 ClosedIssues

小相探索IT世界 4172

Windows 11下JDK 21与JMeter 5.6.3环境配置全攻略

环境变量是操作系统管理软件路径与执行权限的核心机制,它通过预设的键值对,指引系统在调用命令时定位可执行文件。理解其工作原理,是解决软件安装后“命令未找到”等问题的关键。对于Java生态而言,正确配置JAVA_HOME和Path变量,不仅能让java、javac等基础命令全局可用,更是Maven、Gradle乃至JMeter等众多工具链顺畅运行的基石。JMeter作为一款基于Java开发的经典性能测试与接口测试工具,其稳定运行高度依赖健全的Java环境。本文聚焦于在Windows 11系统上,为JDK 21与

weixin_30940783的博客 449

Git 提交注释的常见规则和最佳实践

Git 提交注释的最佳实践

ChinaLiaoTian的博客 3353

ADC噪声参数博弈论:为何24位ADC的有效分辨率可能不如16位?

本文深入探讨了ADC噪声参数的核心矛盾,揭示了24位ADC有效分辨率可能不如16位ADC的根本原因。关键在于跳出单纯比较位数的误区,转而关注输入参考噪声这一绝对指标。文章通过分析参考电压对满量程范围和噪声模型的影响,阐述了动态范围与最小可测信号之间的取舍逻辑,为工程师提供了基于系统实际需求的ADC选型与噪声评估框架。

snow3的博客 704

嵌入式开发避坑指南:用DWT做延时函数,这几个细节不注意代码会跑飞

本文深入探讨了在Cortex-M嵌入式开发中使用DWT实现精确延时函数的关键技巧与常见陷阱。针对DWT_CYCCNT计数器应用中的内核兼容性、溢出处理、编译器优化等五大核心问题,提供了工业级稳健解决方案,帮助开发者避免代码跑飞风险,实现微秒级高精度延时控制。

weixin_42653691的博客 158

git提交注释规范

ci:主要目的是修改项目继续完成集成流程(例如Travis,Jenkins,GitLab CI,Circle)的提交。build: 主要目的是修改项目构建系统(例如glup,webpack,rollup的配置等)的提交。scope用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。chore:其他的小改动. 一般为仅仅一两行的改动, 或者连续几次提交的小改动属于这种。refactor:重构(即不是新增功能,也不是修改bug的代码变动)用于说明 commit 的类别。

忘川 2440

vivado:差分信号和单端信号 的相互转换 IBUFDS OBUFDS

FPGA能处理的都是单端信号,但有些输入信号是差分的,这时候就需要把差分信号转为单端信号。

qq_52137732的博客 1万+

如何规范Git提交注释

如何规范Git提交注释Git提交注释的构成Git提交注释的7个好规则Separate subject from body with a blank line / 使用空行分割主题与内容Limit the subject line to 50 characters / 主题行限制为50个字符Capitalize the subject line / 主题行首字母大写Do not end the subject line with a period/ 主题行行尾不添加句号Use the imperative

信天翁的博客 2416

ANSYS CFX 自定义函数数据导入实战指南

本文详细介绍了在ANSYS CFX中实现自定义函数数据导入的完整流程与实战技巧。通过具体案例,指导用户如何将外部实验或计算数据(如材料属性随温度变化)导入CFX,创建可调用的函数,并正确关联到仿真模型中,从而显著提升仿真的真实性与准确性。

v6b7n8m9q0的博客 703

FA 新增资产API Demo

DECLARE l_trans_rec fa_api_types.trans_rec_type; l_dist_trans_rec fa_api_types.trans_rec_type; l_asset_hdr_rec fa_api_types.asset_hdr_rec_type; l_asset_desc_rec fa_a

chosen1brain的专栏 2142

git commit 提交注释规范

本文将介绍使用git commit时的注释规范,提高commit内容的可读性及理解。

傲雪星枫 2万+

matlab 点云泊松盘采样

本文介绍了泊松盘采样算法在三维点云处理中的应用。该算法通过最小间距约束(任意两点距离≥r)和均匀分布特性,生成高质量、均匀分布的点集。文章详细阐述了参数设置(如采样半径、候选点数),并与体素栅格、随机采样等方法进行了对比。代码实现部分展示了MATLAB版本的泊松盘采样算法,包括KD树加速和候选点生成机制。实验结果表明,该方法能有效保持点云特征,适用于点云简化、曲面重建等场景。文中还提供了参数调整建议和不同应用场景下的使用指导。

点云侠的博客 537

【Git】Git commit 注释规范

【Git】Git commit 注释规范 1 前言 规范的注释方便自己进行合并、撤消、回退。当代码有几十个分支,有成千上万条提交时,你随时可能面临着合并分支,回退代码,舍弃代码,对比代码,复制历史记录中有用的代码片段等等。如果仅靠千篇一律的注释,是很难从快速从注释中提取有用的信息,并且会遇到选择困难,不知道要合并哪个点,不知道要回退到哪里等。而传统的tag是用来记录大版本号,或发布时使用的。 2 注释格式 [标签]:[注释内容] 标签的作用是快速识别和判断出当前提交的内容的...

南方有乔木的博客 1382

手把手教你学PCIE(5.1)--pcie固件初始化的硬件初始化

PCIe 固件初始化的硬件初始化是一个复杂但至关重要的过程。通过正确配置 PCIe 控制器和相关硬件,可以确保系统的稳定性和性能。以上步骤和示例代码提供了一个基本的框架,实际开发中可能需要根据具体的硬件和需求进行调整和优化。

MHD0815的博客 1689

老版QQ原生表情gif动态

这是老版的QQ表情,不过全是动态的的,Windows照片查看器是不会动的,可以右击用浏览器打开查看,再说一遍是老版的,只是分享给宁愿用老版也要动态的人。

git提交代码注释信息规范

git commit -m “本次提交注释信息规范” JIRA-1234 feat: support for async execution ^-------^ ^--^: ^-------------------------^ | | | | | +--> Summary in present tense. | | | +--> Type: feat, fix, docs, style, refactor, pe

weixin_43623808的博客 2999

efm32 入门.pdf

本PDF共计22页,介绍的是操作驱动API,下载与否自己斟酌。

Git提交代码注释信息规范-相关命令汇总

Git提交代码注释信息规范-相关命令汇总

天道酬勤 9962

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

Git提交注释前缀规范

前言 昨天看到了明源云技术公众号发布了一篇关于 Git Commit 注释规范的文章,刚好我们团队这一块还没有相关规范便记录下来。 规矩是死的,人是活的。不一定按照他们的规范来,懂得利用好注释才是最终目的。 除了常规的描述信息外,应该按类型进行备注。方便下次codereview。 feat : 新特性 fix: 修改问题 refactor: 代码重构 docs: 文档修改 chore: 其他修改 test : 测试用例修改 style : 代码格式修改 ...

weixin_43725548的博客 767

GIT注释规范推荐

GIT释规范推荐 为什么需要规范 无规矩不成方圆,编程也一样。 如果你有一个项目,从始至终都是自己写,那么你想怎么写都可以,没有人可以干预你。可是如果在团队协作中,大家都张扬个性,那么代码将会是一团糟,好好的项目就被糟践了。不管是开发还是日后维护,都将是灾难。 这时候,有人提出了何不统一标准,大家都按照这个标准来。于是 ESLint,JSHint 等代码工具如雨后春笋般涌现,成为了项目构建的必备良品。 Git Commit 规范可能并没有那么夸张,但如果你在版本回退的时候看到一大段糟心的 Commit,恐怕

大白菜 928

Git提交注释规范

Git提交注释规范

记录工作的常用技术、技能技巧 632

Git:注释规范

提交格式 <type>(<scope>): <subject> // 空一行 <body> 说明 type(必需) 用于说明 commit 的类别 br: 此项特别针对bug号,用于向测试反馈bug列表的bug修改情况 feat:新功能(feature) fix:修补 docs:文档(documentation) style: 格式(不影响代码运行的变动) refactor:重构(即不是新增功能,也不是修改bug的代码变动) ..

MQ0522的博客 1164

别再只会用-m了!Git提交注释的进阶玩法(附emoji表情规范)

本文深入探讨了Git提交注释的进阶技巧,包括多行注释的编写方法、专业团队的注释规范以及如何通过emoji表情提升提交信息的可读性。特别介绍了Conventional Commits规范和团队协作的标准化配置,帮助开发者提升版本控制效率。

dapp9builder的博客 63

Git注释规范

主打一个有用……

https://github.com/amoorzheyu 457

Git commit注释规范

* type用于说明 commit 的类别,只允许使用下面8个标识。 * br: 此项特别针对bug号,用于向测试反馈bug列表的bug修改情况 * feat:新功能(feature) feat:功能描述 [taskId] * fix:修补bug * docs:文档(documentation) * style: 格式(不影响代码运行的变动) * refactor:重构(即不是新增功能,也不是修改bug的代码变动) * test:增加测试 * chore:构建过程或辅助工具的变动 *

809

Git提交规范全攻略:naming-convention中的注释约定最佳实践

在软件开发中,**Git提交规范**和**命名约定**是团队协作的基石。naming-convention项目提供了完整的Git提交注释约定模板,帮助开发者编写清晰、一致的提交信息,提升代码审查效率和项目可维护性。本文将详细介绍如何运用这些最佳实践来优化你的Git工作流。 ## 📝 为什么Git提交规范如此重要? 良好的提交规范不仅仅是形式主义,它能带来实实在在的好处: ✅ **提高代码可

gitblog_00744的博客 1051
上一篇: druid-spring-boot-starter 用法
下一篇: SpringCLoud Gateway 与 Swagger聚合
cashZhang27
博客等级 码龄10年 22粉丝 67原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值