Git笔记
官网
下载：
git的提交规范
Git提交规范是为了确保代码提交信息清晰、一致、易于理解和跟踪。以下是常见的Git提交规范，您可以根据需要进行调整和使用：
1. 提交信息格式
提交信息通常由标题、描述和正文组成，格式如下：
<type>(<scope>): <subject>
<body>
<footer>2. 类型（type）
常见的提交类型包括：
- feat: 增加新功能
- fix: 修复Bug
- docs: 仅文档更改
- style: 不影响代码含义的更改（空白、格式、缺少分号等）
- refactor: 既不是修复bug也不是添加新功能的代码重构
- perf: 提高性能的代码更改
- test: 添加或修改测试
- chore: 影响构建系统或外部依赖的更改（如：更新npm包，修改构建任务）
- revert: 恢复先前的提交
3. 作用域（scope）
作用域指的是此次更改的影响范围，可以是以下任意一个：
- 模块或功能名称（如：用户管理、支付模块）
- 文件或目录名称（如：components、utils）
4. 标题（subject）
标题是对此次更改的简要描述，注意以下几点：
- 使用祈使语气，例如：修复登录页面Bug，而不是修复了登录页面Bug
- 首字母小写
- 不超过50个字符
- 结尾不要加句号
5. 正文（body）
正文对提交进行详细描述，说明代码更改的原因、方式和目的：
- 使用祈使语气
- 每行不超过72个字符
- 解释“是什么”和“为什么”而不是“怎么做”
6. 页脚（footer）
页脚用于列出不兼容变更和关闭的任务编号：
- 如果提交是一个破坏性变更，页脚应该以 BREAKING CHANGE: 开头，后面是对变更的描述、变更原因和迁移方法。
- 如果是关闭某个issue，页脚可以使用类似 Closes #123 的格式。
示例
好的，以下是一个中文的Git提交信息示例：
feat(用户管理): 添加用户登录功能
增加了用户使用邮箱和密码登录的功能。
该功能包含前端和后端的实现。
BREAKING CHANGE: 登录接口现在需要认证。
Closes #45以下是不同类型的中文提交示例：
新功能（feat）
feat(支付模块): 增加支付宝支付功能
增加了用户可以使用支付宝进行支付的功能。
该功能包括支付请求和支付结果处理。Bug修复（fix）
fix(订单管理): 修复订单无法取消的Bug
修复了用户在特定情况下无法取消订单的问题。
原因是订单状态判断逻辑有误。文档更改（docs）
docs(README): 更新安装步骤
更新了README文件中的安装步骤，增加了对新依赖项的说明。代码格式（style）
style(代码格式): 调整代码格式
调整了代码的缩进和空行，以提高代码的可读性。
不涉及功能逻辑的更改。代码重构（refactor）
refactor(用户管理): 重构用户验证逻辑
重构了用户验证逻辑，将其从控制器中分离出来放到独立的服务中。性能优化（perf）
perf(查询优化): 优化数据库查询性能
优化了订单查询的数据库查询语句，减少了查询时间。添加测试（test）
test(用户管理): 添加用户登录功能的单元测试
为用户登录功能添加了单元测试，覆盖了主要的登录场景。构建系统或外部依赖的更改（chore）
chore(依赖): 升级lodash版本
升级了lodash库的版本以修复已知的安全漏洞。恢复先前的提交（revert）
revert: 恢复 "feat(支付模块): 增加支付宝支付功能"
此提交恢复了先前错误的提交，支付宝支付功能将暂时移除。在创建仓库并初始化项目框架时，提交信息可以简洁明了，通常包含以下内容：
提交信息示例
chore: 初始化项目框架
创建了项目的基础文件夹结构，并添加了必要的配置文件。创建仓库、一些文件夹，初始化项目框架
chore: 初始化项目框架
创建了项目的基础文件夹结构，并添加了必要的配置文件。
文件夹结构：
- src/: 源代码文件夹
- tests/: 测试文件夹
- docs/: 文档文件夹
添加的配置文件：
- .gitignore: Git忽略文件配置
- README.md: 项目介绍文件通过这种方式，团队成员可以一目了然地了解项目的初始设置。
通过这种规范化的提交信息，团队成员可以更清晰地了解每次提交的目的和影响，有助于项目的长期维护和协作。
通过遵循这些规范，可以帮助您和您的团队更好地管理代码提交历史，提高项目的可维护性和可读性。