实际工作中 Git Commit 代码提交规范是什么样的？

转载 于 2025-06-23 14:40:15 发布 · 21 阅读 · 0
文章标签：

#git

前言

Git 是我们日常工作中使用最为广泛的分布式版本代码控制系统，因此在我们的实际工作中，git commit 代码提交规范能够让每一次代码提交都变得有据可循，方便后续的代码审查、问题追踪和版本管理。同时，规范的提交信息也能够为自动化工具提供便利，如生成变更日志、自动化部署等。

git commit 规范写法示例

首先我们一起来看看行业统一认可且标准的 angular 项目的 git commit 规范写法。

基本格式

首先一个规范的 git commit message 通常包含 Header、Body 和 Footer 三部分，各部分之间使用空行分隔。

<header>
// 空一行
<body>
// 空一行
<footer>

Header 必填

描述提交类型和简短说明。格式为：<类型>(<作用域>): <主题>(<type>(<scope>): <subject>)。

  • 类型（Type）： 必填，指明本次提交的目的，如 feat 表示新开发的功能（feature）、fix 表示修复 bug、refactor 表示代码重构等。
  • 作用域（Scope）： 可选，描述修改的影响范围，如模块名、功能名等，视项目不同而不同。
  • 主题（Subject）： 必填，是 commit 简明扼要的提交描述。长度建议不超过 50 个字符。
feat(payment): 微信支付功能集成

Body 可选

详细说明本次 commit 修改的内容。使用空行分隔段落，保持可读性。

- 新增微信支付SDK依赖
- 实现支付结果回调处理
- 添加支付相关的单元测试

Footer 可选

主要用于关联 Issue、描述破坏性变更（BREAKING CHANGE）等。

Closes #889
BREAKING CHANGE: 旧版支付回调接口已废弃，需迁移至 /api/v2/callback

实际工作常用的 git commit 规范写法

其实在实际开发工作中很多时候我们主要关注和使用的是 git commit message 的 Header 部分。Header 通常包含了提交的类型、作用域和简短的主题描述，这些信息对于快速了解每次提交的内容和目的已经足够。

描述提交类型和简短说明。格式为：<类型>(<作用域>): <主题>。

格式：type(scope) : subject

常用的提交类型包括

提交类型描述示例
feat新功能增加（feature）feat: add user login feature
fix修复BUGfix: correct user authentication
refactor代码重构（既不是新增功能，也不是修复 Bug）refactor: simplify user validation logic
docs文档/注释docs: update API documentation
style代码风格相关无影响运行结果的style: format code with prettier
test测试相关test: add unit tests for login feature
build影响构建系统或外部依赖的更改（例如：gulp，broccoli，npm）build: update webpack config
revert代码撤销修改revert: revert commit 12345abc
ci持续集成的配置文件和脚本的变动（例如：Travis，Circle，BrowserStack，SauceLabs）ci: update Travis configuration
chore依赖更新/脚手架配置修改等chore: upgrade React to the latest version
perf性能优化perf: optimize virtual DOM diffing algorithm

Git 相关学习资料

原创作者: Can-daydayup 转载于: https://www.cnblogs.com/Can-daydayup/p/18881315
孔李聃丘
关注
Git的约定式提交
Criss@陈磊
02-25 467
Git的约定式提交 约定式提交规范是一种基于提交消息的轻量级约定。它提供了一组用于创建清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易，在提交信息中描述新特性、bug修复和破坏性变更。 约定式提交 很多时候，大家都会在约束git的commit的message，但是绝大部分都会约束commit的message不为空即可。这是一个很好的工程实践的开始，但是随着时间的推移你会发现绝大部分人的commit的message都是无用的废话，例如”修复bug“、”添加新功能“等等，这些看似有有用的描
3、持续集成流水线实践：Git的约定式提交
Criss@陈磊
02-25 342
Git的约定式提交 约定式提交规范是一种基于提交消息的轻量级约定。它提供了一组用于创建清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易，在提交信息中描述新特性、bug修复和破坏性变更。 约定式提交 很多时候，大家都会在约束git的commit的message，但是绝大部分都会约束commit的message不为空即可。这是一个很好的工程实践的开始，但是随着时间的推移你会发现绝大部分人的commit的message都是无用的废话，例如”修复bug“、”添加新功能“等等，这些看似有有用的描
git commit 命令详解
热门推荐
辰风沐阳
01-15 9万+
git commit 命令用于将工作区内容或暂存区内容提交到版本库本文记录 git commit 的常见用法，日常开发中，这几个参数足够使用了# 将暂存区内容提交到版本库, 进入 vi 命令界面输入提交信息git commit# 将某些已被跟踪的文件提交到版本库（包含工作区和版本库）# 将暂存区内容提交到版本库, 无需进入 vi 命令界面输入提交信息# 跳过 git add, 将所有已被跟踪的文件更改提交到版本库# 使用一次新的commit, 替代上一次提交。
Git commit提交规范
小小渔夫
12-13 801
使用git管理代码的同行，我们经常能看到其他人代码提交时的备注写的过长，有的看不懂，有的太过间接，本文旨在简单说明git commit提交的规范，规范提交内容。
Commit提交规范
qq_43203586的博客
09-26 2057
Commit提交规范 整体上根据 angular 规范提交 commit，细微处做了修改。 <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> （1）type 提交 commit 的类型，包括以下几种 feat: 新功能 fix: 修复问题 docs: 修改文档 style: 修改代码格式，不影响代码逻辑 refact
代码工程必备能力—Commit 规范
benjaminparker的博客
10-24 6399
Git是目前应用最为广泛的开源分布式版本控制系统，不论是对企业团队还是科研任务都需要掌握使用Git的技巧，文章重点在于总结如何使用Git的一些功能，包括讲述的文章、资源和个人的想法。 Git 官方网址：Git 一. Git Commit 的作用（干啥用的） Git Commit：指的是提交说明，用于标注此次修改的内容以及需要提示的信息,官方给出的解释是：Record changes to the repository（记录添加到仓库当中的修改）。 提供一个场景来做...
Git提交规范流程和解决冲突实际使用
年少有为
02-24 1286
前言：GIT对于我们程序员来说是吃饭的工具，本篇主要是针对提交和分支以及对于大多数程序员闻风丧胆的冲突一些个人见解，如果有啥不对的或者你们公司git提交流程欢迎下方评论。 在讨论规范之前，我们需要定最基本的要求 1.团队内保持良好的代码格式便于易读和维护，最主要减少不必要的代码冲突（建议统一使用开发工具（idea）的代码格式化）。 2.提交任何代码必须确认代码可运行 3.提交的代码必须移除无用的包路径引用和无用的依赖，尽量不要使用过期的方法或者类 1 .commit message规范 规范格.
git版本管理和使用 1
liyongchunscr的博客
10-10 605
一：安装 Git 在使用Git前我们需要先安装 Git。Git 目前支持在 Linux/Unix、Windows，Mac平台上运行。 可点击 Git官网 下载安装程序。 1：如何在 Windows 上安装 Git 第一步：进入官网后，点击 Windows，页面跳转 第二步：跳转后如下图所示 因为访问的是外网，所以网速会很慢很慢。我下载好的安装包放到了大家都懂的地方，之前保留的 Git-2.21.0 版本被我不小心给删了，这里我重新上传一个 Git-2.23.0-64-bit 版本的..
(六)Git内幕原理
厚积薄发
03-14 449
代码提交的内幕原理 （一）git数据存储机制 1）git hash-object git的数据存储格式实际上是一种非常简单的key-value存储格式。就是说，git支持将任何东西存储到其数据库中， 一般就是存储文件的内容，然后用一个key值来引用它。 首先随便找一个目录，初始化为git项目： git init 此时去.git/objects目录中检查一下，发现只有两个子目录，info和pack，没有任何文件，此时数据库是空的。 用下面命令，可以手动...
git commit 规范指南
weixin_34375233的博客
04-13 1235
前言 Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。但是，一般来说，commit message 应该清晰明了，说明本次提交的目的。 不过话说回来，作为最具个人创造力和最会利用工具的物种——程序猿，最好是能有规范和工具的约束。否者的话，你可能看到以下的commit message： 目前，社区...
commit 提交规范
weixin_34247032的博客
03-25 5303
commit 格式 <type>(<scope>) : <subject> <空行> <body> <空行> <footer> 复制代码 type：本次提交的类别，必填 scope：影响范围，可以不填 subject：提交的标题，一句话概括提交的内容 body：详细描述提交的内容，可以不填 footer：放置写备注...
Git：Commit Message 规范和代码格式校验
大空翼 つばさ
11-13 9483
Commit Message 规范 以 angular 规范为例，格式如下： type(scope): subject # head 必填，其中 type 和 subject 必填。 # 空行 72-character wrapped. # body 选填。 ...
git commit命令详解
killer1989的博客
06-11 2万+
按照git的步骤，要提交一个新的文件，或者一个修改过的文件分3步 第1步：将文件放入版本库的目录（貌似说的是废话） 第2步：用 git add 文件名（最好是全英文，尤其是在windows下） 第2.5步 用git status 命令 查看状态（这一步是良好的习惯，但不是必要，这样在修改、删除或者新建的文件比较多的时候能够避免错误） 这里具体讲解一下，状态主要分为三种状态 1）Untra
Git commit格式参考
noahsun1024的博客
03-22 942
前言 文章首发于Noah Sun’s Home Git commit格式参考，转载请注明出处，谢谢！ 编写良好的Commit messages可以达到以下几个重要的目的 加快review的流程 帮助我们编写良好的版本发布日志 让之后的维护者了解代码里出现特定变化和feature被添加的原因 目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法...
关于Commit message代码提交
小羊咩咩的博客
07-02 2129
Commit message代码提交规范 目录相关参考链接 相关参考链接 Commit message 代码提交规范 Git 提交的正确姿势：Commit message 编写指南 commit message格式规范 Commit message 和 Change log 编写指南 Git 提交的正确姿势：Commit message 编写指南 【Git学了就忘-实操（二）】修改已提交commit的message commit message：提交说明 ...
提交信息规范
weixin_33751566的博客
12-17 425
commit message格式说明commit message一般包括三部分：Header、Body和Footer。 Headertype(scope):subject type：用于说明commit的类别，规定为如下几种 feat：新增功能；fix：修复bug；docs：修改文档；refactor：代码重构，未新增任何功能和修复任何bug；build：改变构建流程，新增依赖库、工具等（例如...
代码管理和软件配置管理应该怎样做？| 研发效能提升36计
BYvonne的博客
02-10 964
效能提升从小习惯开始，这样才是代码管理和 Commit 的正确姿势！
标准的git commit写法
youshuang1207的博客
04-06 274
git commit -m 'feat: xxx功能开发' git commit -m 'fix(account): 修复xxx的bug'
提交标题和正文内容有什么区别
最新发布
03-29
<think>嗯，用户之前问过如何获取更多的提交信息，比如日志的详细信息，现在他们又想知道提交标题和正文的区别。看起来他们可能是在使用Git进行版本控制，想要更好地组织他们的提交信息。 首先，我需要确认用户对Git的基本概念是否了解。提交标题和正文是Git提交信息的两部分，但用户可能不清楚它们各自的用途和最佳实践。用户可能遇到了提交信息混乱的问题，或者想提高项目的可维护性，所以需要明确区分这两部分。 接下来，我应该解释标题和正文的不同之处。标题是简短描述，正文是详细说明。比如标题要简明扼要，正文可以分点说明改动的原因、影响等。还要提到一些约定，如标题行不超过50字符，正文每行72字符，这些是常见的规范，但用户可能不知道。 然后，用户可能需要示例来理解。给出一个具体的例子，展示好的标题和正文是什么样的，以及不好的例子作为对比。这样用户能直观看到区别。 另外，用户可能想知道如何在实际操作中编写这样的提交信息，比如使用git commit命令时如何输入多行内容，或者使用-m和-F选项的区别。可能还需要提醒他们使用某些工具或IDE时如何正确输入正文内容。 最后，总结两者的区别，强调清晰提交信息的重要性，帮助团队协作和后期维护。可能还要提到相关的最佳实践，比如约定式提交，让用户有进一步学习的资源。</think>在版本控制系统（如 Git）中，提交的**标题（Subject）**和**正文（Body）**是提交信息（Commit Message）的两个组成部分，它们的核心区别如下： --- ### 一、提交标题（Subject） #### 1. **核心作用** - **简短概括**：用**一行**简明描述提交的**核心目的**。 - **快速索引**：在日志浏览（如 `git log --oneline`）时直接显示标题，帮助快速定位提交。 #### 2. **格式要求** - **首字母大写**：例如 `Fix: Update login validation`。 - **长度限制**：通常不超过 **50 个字符**（避免被截断）。 - **动词开头**：使用 `Fix`, `Add`, `Update`, `Remove` 等动词明确动作。 - **无结尾标点**：一般不使用句号 `.`。 #### 3. **示例** ```plaintext Fix: Resolve user login timeout issue ``` --- ### 二、提交正文（Body） #### 1. **核心作用** - **详细解释**：多行文本，说明**为什么修改**（动机）、**如何实现**（方法）、**影响范围**。 - **补充细节**：描述技术细节、关联问题（如 Issue 编号）、注意事项。 #### 2. **格式要求** - **空行分隔**：标题和正文之间需有**一行空白行**。 - **段落清晰**：可分段或分条目（用 `-` 或 `*` 符号）。 - **行长限制**：每行建议不超过 **72 字符**（避免自动换行混乱）。 - **使用完整句子**：可包含标点符号。 #### 3. **示例** ```plaintext Fix: Resolve user login timeout issue - 增加 Redis 连接池配置，防止数据库连接耗尽 - 修复 Session 过期时间计算错误（原为毫秒，应为秒） - 关联 Issue: #123 ``` --- ### 三、对比表格 | 特性 | 提交标题 | 提交正文 | |---------------------|---------------------------|---------------------------| | **长度** | 单行，≤50 字符 | 多行，每行 ≤72 字符 | | **内容重点** | **做了什么** | **为什么做、如何做** | | **显示场景** | `git log --oneline` | `git log` 完整查看 | | **标点符号** | 无句号 | 可正常使用标点 | | **强制要求** | 必填 | 可选（简单提交可省略） | --- ### 四、实际提交示例 #### 好的提交信息 ```plaintext Feat: Add user profile image upload - 支持上传 PNG/JPG 格式图片（限制大小 5MB） - 使用 AWS S3 存储文件，生成访问签名 URL - 修复上传时文件名特殊字符转义问题 ``` #### 差的提交信息 ```plaintext fix bug ``` --- ### 五、操作建议 1. **命令行提交**： - 单标题提交：`git commit -m "Fix: Correct API endpoint"` - 标题+正文提交：用 `git commit`（不接 `-m` 参数）打开编辑器输入多行内容。 2. **工具辅助**： - 使用 IDE（如 VSCode、IntelliJ）的 Git 插件，可直观分栏输入标题和正文。 3. **规范参考**： - **约定式提交（Conventional Commits）**：标准化提交格式（如 `fix:`, `feat:`, `BREAKING CHANGE:`）。 --- 通过区分标题和正文，可以显著提升提交信息的可读性和可维护性，尤其在团队协作或回溯代码历史时作用关键。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值