Git 提交前缀规范

最新推荐文章于 2025-06-05 16:13:56 发布

原创最新推荐文章于 2025-06-05 16:13:56 发布 · 988 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#git

本文探讨Git提交时的规范，强调新功能添加、bug修复、文档更新的重要性和代码结构管理的不同类别，如代码格式化、重构和测试用例等。

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

Git 提交前缀规范

feat : 新功能。添加一个新的用户界面元素、一个新的功能或一个新的 API
fix : 修复 bug。修复一个导致应用程序崩溃的错误、一个导致数据丢失的错误或一个导致用户体验不佳的错误
docs : 文档更新。更新你的应用程序的用户指南、更新你的 API 文档或更新你的技术文档
style : 代码格式化。不影响代码运行的变动
refactor : 代码重构。包括重命名变量、移动代码块或更改代码结构。
test : 测试用例。
chore : 其他类型的更改。提交更改你的应用程序的构建系统、更改你的应用程序的依赖项或更改你的应用程序的配置文件。

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

偷光

关注关注

9
点赞
踩
9

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

git分支管理和git提交规范

winne雪

04-20

3799

一、git分支管理一般情况下的分支管理如下： master分支：一般用于存放正式环境上的代码，每次发版到正式时才更新，其他时间不允许修改。（每次发版后可以打个tag，标记这次大版本的发布。如果有重大bug修复发的小版本可以打大版本下的小版本tag） bug分支：万一正式环境出现严重bug妨碍使用时需要创建个bug分支进行修改，然后同步到release分支进行测试。测试后再同步到master分支发布，然后还要同时同步到iteration分支、develop分支 release分支：测试环境上的分支，开发完所

笔记——Git Commit 提交规范

蜡笔小谢的博客

01-16

5744

在团队协作中，合理的提交规范能够帮助开发者提高代码质量、简化代码审查流程，并促进更高效的团队协作。本文介绍 Git commit 提交规范的重要性，并分享一些最佳实践，帮助开发者更好地管理和记录代码提交。

参与评论您还未登录，请先登录后发表或查看评论

Git提交前缀标准

xu_xin96的博客

02-25

2153

1. **feat：** 新功能（feature）的提交。 2. **fix：** 修复（fix）bug 的提交。 3. **docs：** 文档（documentation）更新的提交。 4. **style：** 代码风格（code style）更新，不涉及功能或 bug 的更改。 5. **refactor：** 代码重构（refactoring）的提交，既不是修复 bug 也不是添加新功能。 6. **perf：** 性能优化（performance optimization）的提交。

Git提交消息中的feat、fix等前缀详解：提升团队协作效率

最新发布

随便写写

06-05

1588

Git提交消息规范指南规范化的Git提交消息对团队协作至关重要。本文介绍了常见提交前缀及其使用场景： feat：新增功能 fix：错误修复 docs：文档变更 style：代码格式调整 refactor：代码重构 perf：性能优化 test：测试相关 chore：构建工具变动 revert：回退提交推荐遵循Conventional Commits规范，格式为：<type>[scope]: <description>。使用Commitizen等工具可辅助生成规范提交。规范的提交消息能提升代码可维护性

git提交规范，前缀解释（之前居然不知道这是啥）

zhou269517的博客

06-05

556

5、refactor: 重构（即不是新增功能，也不是修改bug的代码变动）3、docs: 文档（documentation）4、style: 格式（不影响代码运行的变动）6、chore: 构建过程或辅助工具的变动。1、feat: 新功能（feature）10、improvement: 改进。7、revert: 撤销，版本回退。2、fix: 修补bug。8、perf: 性能优化。11、build: 打包。13、update:更新。12、ci: 持续集成。

Git提交前缀

Jason~JiaoJiaoOne

04-16

671

通过这些规范化的标签，团队成员可以快速理解每次提交的主要目的和改动范围。

git 提交前缀

github_39333092的博客

08-07

1189

feat (feature) ：新功能 fix (bug fix)：修复bug docs (documentation) ：文档 style (formatting, missing semi colons, …)：格式 refactor：重构 test (when adding missing tests)：增加测试 chore (maintain)：辅助工具变动 ...

Git 完整的提交规范教程

余十步的博客

07-06

2232

本文中的关键词 “必须（MUST）”、“禁止（MUST NOT）”、“必要（REQUIRED）”、“应当（SHALL）”、“不应当（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“可以（MAY）” 和 “可选（OPTIONAL）”

软件工程领域Git的代码提交规范检查工具

软件工程实践的博客

05-18

681

在现代软件开发中，Git已成为版本控制的事实标准。随着团队规模扩大和项目复杂度增加，统一的代码提交规范对于维护项目可追溯性和可维护性变得至关重要。本文旨在全面介绍Git代码提交规范检查工具的技术实现，帮助开发团队建立高效的代码提交质量控制机制。本文首先介绍Git提交规范的基本概念，然后深入分析检查工具的技术原理，接着通过实际案例展示具体实现，最后讨论应用场景和未来发展趋势。Git Hook：Git在特定重要动作发生时触发的自定义脚本：代码提交时附加的描述信息：一种广泛采用的提交消息规范标准。

git-commit-emoji：Git提交表情符号是用于在Git提交消息上使用的表情符号的标准

02-05

Git提交表情符号（Git Commit Emojis）是一种在Git提交消息中使用表情符号的约定，它为不同的代码更改类型提供了一种视觉上更有趣且统一的方式来表达提交的目的。这个标准可以帮助团队成员快速理解代码库的历史记录...

Git 提交类型前缀

好习惯成就伟大

01-08

1470

这些前缀可以让你更好地描述代码更改的类型，使提交历史更易于阅读和理解，并帮助你在团队中进行协作。Git 提交类型前缀是指在 Git 提交消息中用来描述代码更改类型的前缀。ci：与 CI (持续集成) 相关的更改，例如添加 Travis CI 配置文件、更新 GitHub Actions 等。chore：与构建过程或辅助工具相关的更改，例如更新依赖、构建脚本等。docs：文档相关的更改，例如更新文档、添加注释等。test：测试相关的更改，例如添加或更新测试用例。perf：性能优化相关的更改。

git报错husky ＞ pre-commit hook failed (add --no-verify to bypass)

SnowLee

08-30

621

今天在公司提交代码的时候，步骤没问题，但是报了错误 husky > pre-commit hook failed (add --no-verify to bypass) 网上搜了方法，删除pre-commit文件，发现不能解决，后来重新手动输入（如下图所示）在fix()后面加上了空格，然后就神奇地成功了，吐血~~~~~~~~~~ 此外这里的fix不是随便写的，参考下面的标准 feat: 新功能（feature） fix: 修补bug docs: 文档（documentation） style: 格

git代码提交规范

nil

03-02

1249

git提交规范

geng1025的博客

06-18

4269

(7) build：改变构建流程，新增依赖库、工具等（例如webpack修改）；(8) style：仅仅修改了空格、缩进、注释等，不改变代码逻辑的变动；(6) refactor：代码重构，未新增任何功能和修复任何bug；(3) fix：修复bug、解决冲突（尽量避免）；(10) chore：非src和test的修改；(11) test：测试用例的新增、修改；(9) perf：改善性能和体现的修改；（4）modify：修改xx页面xx功能。(12) ci：自动化流程配置修改；

Git 提交信息的规范中特定的前缀含义

weixin_42202992的博客

03-20

514

Git 提交信息的规范中特定的前缀含义

Git提交前缀规范

u011135963的博客

01-25

829

Git提交前缀规范

Git的提交规范

程序员

02-15

733

Git的提交规范

Git代码提交信息规范

卓越之识论道，平常之识论事，狭隘之识论人

10-23

1611

git提交代码信息规范

05-08

<think>好的，我现在需要回答用户关于Git提交代码信息规范的最佳实践的问题。首先，我得回顾一下用户的问题，确保我理解正确。用户想知道在Git提交代码时，应该如何规范提交信息，遵循哪些最佳实践。根据用户提供的引用，特别是引用[3]提到了使用Commitlint、Husky等工具来规范提交信息，还有Commit Message的格式。同时，引用[4]可能涉及更广泛的编程最佳实践，但这里需要聚焦在Git提交上。首先，我应该整理Git提交规范的主要点。通常，提交信息规范包括提交信息的结构、格式、内容要求等。比如，常见的约定式提交（Conventional Commits）规范，包括类型、作用域、主题、正文和脚注等部分。然后，可能需要提到工具支持，如Commitizen、Commitlint结合Husky来强制规范。然后，我需要参考用户提供的引用内容。引用[3]详细说明了使用Commitlint和Husky来检查提交信息，确保符合规范。因此，在回答中需要包含这些工具的配置和使用方法，但用户可能更关注规范本身，工具是辅助实现的手段。另外，引用[1]和[2]涉及分支管理和标签实践，可能不直接相关，但用户的问题集中在提交信息上，所以可以暂时忽略这些部分。接下来，我需要组织回答的结构。通常，最佳实践可能包括以下几点：提交信息的结构（如类型、主题、正文、脚注）、使用动词时态、避免模糊信息、分离关注点（每次提交一个功能或修复）、引用相关问题等。同时，工具的使用也是规范执行的重要部分，需要简要提及。要注意用户的示例中提到了中文回答，所以需要用中文清晰表达。另外，按照用户的系统级指令，行内数学表达式用$...$，但这里可能用不上，但需要确保LaTeX语法正确，不过提交信息规范不涉及数学公式，所以可能不需要处理这部分。独立公式可能也不适用，但需要检查是否有其他格式要求。用户可能希望了解具体的规范示例，比如类型列表（feat、fix、docs等），以及每个类型的使用场景。同时，可能还需要说明如何编写主题行，比如长度限制、使用祈使语气等。另外，根据引用[3]的内容，Commit Message的规范通常包括首行类型和主题，然后是正文和脚注，比如： feat(api): 新增用户登录接口 Closes #123 这里需要详细说明各个部分的作用，以及常见的类型和格式。同时，用户可能想知道为什么需要这些规范，比如提高可读性、便于生成变更日志、自动化版本号等好处。然后，我需要确保回答的结构清晰，分点说明，可能使用标题如“1. 提交信息结构规范”、“2. 内容编写原则”、“3. 工具支持”等。每个部分下再细分小点，比如类型、作用域、主题等。需要检查是否有遗漏的最佳实践，比如多行提交信息的换行、正文和脚注的格式、如何引用问题跟踪系统的编号等。最后，生成相关问题，可能需要考虑用户可能进一步询问的内容，如如何配置Commitlint和Husky，如何处理特殊情况，或者不同团队的规范差异等。现在，我需要将这些思考整合成一个结构化的回答，确保涵盖主要的最佳实践，同时引用提供的引用内容中的相关部分，如引用[3]提到的工具链。</think>### Git提交代码信息规范最佳实践 #### 1. 提交信息结构规范采用**约定式提交规范（Conventional Commits）**，格式如下： ``` <类型>[可选作用域]: <主题> [空行] [正文] [空行] [脚注] ``` - **类型**：定义提交的意图，常用类型包括： - `feat`：新增功能 - `fix`：修复问题 - `docs`：文档变更 - `style`：代码格式调整（如空格、分号） - `refactor`：重构代码（既非新功能也非修复） - `test`：测试相关变更 - `chore`：构建或辅助工具变更 - **作用域**（可选）：说明影响范围，如模块名（例：`feat(api): ...`） - **主题**：简明描述变更，使用**祈使语气**（如“新增”而非“新增了”），长度建议不超过50字 - **正文**（可选）：详细说明变更动机或实现细节，每行不超过72字符 - **脚注**（可选）：关联问题或标记重大变更，如： - `Closes #123`（关闭Issue） - `BREAKING CHANGE: 删除旧API` #### 2. 内容编写原则 - **原子化提交**：每次提交仅解决一个独立问题[^4] - **避免模糊描述**：禁用“更新”“修复”等笼统词汇，需明确具体内容（如`fix: 解决登录接口空指针异常`） - **关联上下文**：通过脚注引用Jira、GitLab等系统的问题编号（例：`Refs PROJECT-123`） #### 3. 工具支持 - **Commitizen**：交互式生成规范提交信息[^3] - **Commitlint + Husky**：通过Git钩子自动校验提交格式（示例配置）： ```bash # 安装依赖 npm install @commitlint/cli @commitlint/config-conventional husky --save-dev # 启用Husky钩子 npx husky install # 配置Commitlint规则 echo "module.exports = { extends: ['@commitlint/config-conventional'] }" > .commitlintrc.js # 添加钩子脚本 npx husky add .husky/commit-msg 'npx commitlint --edit "$1"' ``` #### 4. 示例对比 ❌ 不规范示例： `git commit -m "改了个bug"` ✅ 规范示例： ``` fix(auth): 修复用户登录时的令牌过期问题原逻辑未校验令牌有效期，导致过期后仍可访问敏感接口 Closes #45 ``` ### 常见问题解答 **Q：为何强制要求类型前缀？** A：类型前缀便于自动化生成变更日志（如`feat`和`fix`会体现在版本号中），同时提升代码审查效率[^3]。 **Q：多团队协作时如何统一规范？** A：可通过共享`.commitlintrc`配置文件或代码模板库强制执行[^4]。