Git commit type 规范

最新推荐文章于 2024-04-28 15:38:32 发布
最新推荐文章于 2024-04-28 15:38:32 发布
阅读量2.5k 收藏 2
点赞数 2
分类专栏： Git 文章标签： git
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/CalledJoker/article/details/122349859
版权

git commit 提交规范

提交规范： git commit -m “feat(新增暂停功能): 新增执行推广任务暂停功能”

# 主要type
feat:     增加新功能
fix:      修复bug

# 特殊type
docs:     只改动了文档相关的内容
style:    不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build:    构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert:   执行git revert打印的message

# 暂不使用type
test:     添加测试或者修改现有测试
perf:     提高性能的改动
ci:       与CI（持续集成服务）有关的改动
chore:    不修改src或者test的其余修改，例如构建过程或辅助工具的变动
笔记——Git Commit 提交规范
蜡笔小谢的博客
01-16 5260
在团队协作中，合理的提交规范能够帮助开发者提高代码质量、简化代码审查流程，并促进更高效的团队协作。本文介绍 Git commit 提交规范的重要性，并分享一些最佳实践，帮助开发者更好地管理和记录代码提交。
【知识整理】Git Commit Message 规范
李木
02-23 3030
前面咱们整理过Code Review 一文，提到了 Review 的重要性，已经同过gitlab进行CodeReview 的方式，那么本文详细说明一下对CodeReivew非常重要的Git Commit Message 规范。我们在每次提交代码时，都需要编写 Commit Message，否则是不允许提交的。书写好的 Commit Message 能大大提高代码维护的效率。避免开发人员在项目中群魔乱舞，搞得代码一团糟，搞的项目就被糟践了。且开发日后的维护，都将是灾难。
git分支开发规范指南.pdf
03-26
Git 是目前最流行的源代码管理工具。为规范开发，保持代码提交记录以及 git 分支结构清晰，方便后续维护，现规范 git 的相关操作
git开发规范
yourana123的博客
08-15 253
git规范
Git 开发规范
LitongZero的博客
05-18 1752
Git开发规范 日常开发中，我们经常会跟Git打交道，可能服务器不一样，但是命令和规范基本都是一样的。 一.常驻分支 常驻分支为一个正常开发上线流程应该会有的分支。 1.master/prod/production 主分支，又称为生产环境分支，有时可能会使用（prod/production）来代替，生产环境的部署分支，生产环境相关操作，如：打包等应从改分支进行。 2.dev 全称（Develop），开发分支，我们正常的需求开发等，应该使用该分支。开发环境的部署和打包，使用该分支。 3.pre 全称（Pr
Git开发使用规范
前端小白的逆袭
04-07 506
Git开发使用规范 一、常规操作 （一）克隆项目： git clone 项目仓库地址 [克隆下载的文件夹名] # SSH或HTTP仓库地址都可以，克隆下载的文件夹名非必填 （二）创建个人开发分支命名规则： 功能开发分支名： feature_姓名缩写[_需求简要]_TAPDId (例如：feature_gf_add-dialog_123134) 解决bug分支名： fixbug_姓名缩写[_需求简要]_TAPDId (例如：fixbug_gf_fix-dialog_123134) （三）创建
git使用的开发规范
Android_la的博客
09-02 291
文章目录一. 问题背景二. 步骤 一. 问题背景 在开发中使用git，在本地写完代码后，会执行git push，但是往往会遇到push失败或者要求push前必须pull。然而pull下来后就有很大可能把本地代码覆盖了。本文给出解决方案——正确的git使用开发规范 二. 步骤 首先git clone下来的项目，先使用maven install（IDEA中有可视化按钮）把项目安装到本地库。 一般开发都是一个master分支、一个development分支。我目前所在项目是把development分支给inst
Git Commit提交规范总结
拾年一剑 的专栏
02-27 6866
团队协作中，规范的Git提交记录，使提交历史明确可追溯，有助于更好的协作，方便后期代码的开发和维护
Git Commit提交规范和IDEA插件Git Commit Template的使用
热门推荐
noaman_wgs的博客
12-06 1万+
Git是最牛逼的开源分布式版本控制系统，日常开发中常用来管理代码提交、恢复、追踪，是团队开发最常用的一个代码管理工具。 在我们修改了代码并且提交之前，常会使用git commit -m 'change'命令来描述我们代码改动的内容，但是很多都不规范，随处可见的 git commit -m 'update'，以致于不能清晰地知道每次提交代码的变更内容，所以需要一种规范来管理代码提交的内容。 一、Gi...
Git Commit 规范1
08-03
Git Commit 规范是软件开发过程中非常重要的一个环节，它有助于保持代码库的整洁和历史记录的可读性。在Git中，一个良好的Commit消息能够清晰地表达每次提交的目的和内容，使得团队成员能快速理解代码变更，这对于...
Git协作开发流程规范
10-20
协作必须有一个规范的流程，让大家有效地合作，使得项目井井有条地发展下去。"协作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。协作流程大多采用"功能驱动式开发"（Feature-driven development，简称FDD）。它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
git开发流程规范
08-27
git开发流程规范，及简单代码提交与代码拉取，完整的开发流程。
Git开发规范参考
noahsun1024的博客
03-22 352
前言 文章首发于Noah Sun’s Home Git开发规范参考 ，转载请注明出处，谢谢！ 分支管理 git 的分支管理功能非常强大，为了提高效率、避免分支混乱，我们参考git flow的开发流程规范或者可以直接使用git flow工具。 分支构成 主要分支 master分支：永远处在即将发布（production-ready）状态； develop分支：为开发分支，始终保持最新完成以及bug修...
git 团队开发规范
weixin_39547000的博客
08-13 845
介绍 祖师爷 Linus 在创造了伟大的 Linux 之后，又创造了应用最广泛的代码管理工具 —— Git，极大地提高了程序员的生产力。 现如今大部分项目都在使用 Git 作为代码管理工具，不论是在代码管理、版本控制以及团队协作上，Git 相比其他版本控制软件都有着无可比拟的优势。 虽然 Git 是个优秀的工具，但是在项目中是否能够正确合理地使用，是否能够发挥其最大的优势，就我自己这几年的工作经历来看，对于大部分团队这个问题的答案是否定的。 大部分程序员对 Git 的使用基本上都停留在 git add、gi
基于git的开发规范总结
吴广智的博客
05-10 2401
gitflow工作流是一种依赖于Git版本管理工具，按特定规范对项目开发、测试、上线流程进行管理的工作方式。它是一种为实现规范化管理的约定，它明确了各个分支的意义，使整个团队的分工协作更加清晰。
Git 开发规范流程
杨鑫newlife的专栏
12-14 649
Git 开发规范流程
git 开发规范约定
simuLeo的博客
02-21 396
git 开发规范约定 新增功能： fea-需求号-需求简称（以下划线或驼峰分割的英文单词） 缺陷修复：fix-缺陷号-缺陷简称（以下划线或驼峰分割的英文单词） 紧急修复：hotfix-缺陷号（或修复时间 mmddyyHHMM）-简称 例如：fea-101-AddUserAuth， 表示：需求编号是 101 的“增加用户鉴权” 的功能分支。 ...
送你一份后端必备的 Git 分支开发规范指南
公众号：Java后端
05-04 313
点击上方Java后端，选择设为星标优质文章，及时送达Git 是目前最流行的源代码管理工具。为规范开发，保持代码提交记录以及 git 分支结构清晰，方便后续维护，现规范 git 的相关...
【软件开发规范篇】Git代码提交规范
分享是一种境界，勤于分享，乐于分享！
04-28 4273
本文介绍软件项目开发过程中，代码提交到git仓库，建议遵循的一些规范。每次提交代码到 Git 仓库时，都需要写 commit message。通常情况下，commit message 应该清晰明了，说明本次提交的目的和具体操作等。然而，在日常开发中，开发者们提交的 commit message 千差万别，中英文混用，导致后续代码维护成本很高，有时候甚至自己都不知道修复的是什么问题。因此，为了解决这些问题，建议大家在提交代码的时候，能遵循一些规范或约定，从而提高代码规范，提高开发效率。
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、付费专栏及课程。

余额充值