Git 提交信息（commit messages）、版本号（version）、变更日志（changelog）之间是紧密相关的，它们相辅相成，在项目的开发过程中扮演着重要的角色。通过规范的 Git 提交信息，可以自动生成版本管理、变更记录和发布日志，从而增强团队协作、版本控制和发布流程的透明度和可维护性。
1. Git 提交信息与版本号的关系
版本号是软件发布的标识，用来标明软件的不同发布状态。在大多数现代软件开发中，版本号通常遵循 语义版本控制（SemVer，Semantic Versioning）规范。SemVer 的格式是：
<主版本号>.<次版本号>.<修订号>- 主版本号（Major version）: 破坏性变更（backward incompatible changes）
- 次版本号（Minor version）: 向后兼容的新特性（backward compatible features）
- 修订号（Patch version）: 向后兼容的修复（backward compatible bug fixes）
在软件开发过程中，Git 提交信息是生成版本号和变更日志的依据之一。
版本号更新的标准规则：
- 主版本号更新（Major version）: 如果 Git 提交中包含了破坏性更改（如 API 改动、数据结构变化等），通常会将版本号的主版本号加一。
- 次版本号更新（Minor version）: 如果提交中包含了向后兼容的新功能（新增模块、功能增强等），则次版本号加一。
- 修订号更新（Patch version）: 如果提交中只是修复了 bug 或进行小范围的改进，并且这些更改是向后兼容的，则修订号加一。
通过采用 Conventional Commits 规范（如 BREAKING CHANGE、feat、fix 等），可以自动确定版本号的变化。例如：
feat(auth): add user login feature→ 会增加次版本号。fix(auth): fix password reset bug→ 会增加修订号。BREAKING CHANGE: change login API endpoint→ 会增加主版本号。
自动化版本管理工具：
- standard-version : 基于 Git 提交信息生成版本号，自动更新
package.json中的版本号，并生成变更日志。 - semantic-release: 结合 CI/CD 管道，根据 Git 提交自动生成版本号、发布包和生成 changelog。
2. Git 提交信息与变更日志的关系
变更日志（changelog）是记录软件版本之间差异的文档，详细列出在每个版本中所做的更改。它通常包括每个版本的发布说明，内容可能涉及新的功能、修复的 bug、性能提升等。
使用规范的 Git 提交信息（尤其是 Conventional Commits ）可以帮助自动化生成变更日志。在提交信息中使用特定的关键词（如 feat、fix、BREAKING CHANGE）时，可以自动整理出每个版本的变化内容。
自动生成变更日志的工具：
- Keep a Changelog: 这个网站定义了规范化的 changelog 格式，并且常常和 Git 提交信息格式（如 Conventional Commits）结合使用，帮助开发者创建结构清晰的变更日志。
- standard-version : 不仅可以生成版本号，还可以自动根据提交信息生成
CHANGELOG.md文件，记录每个版本的更改。 - semantic-release: 基于 Git 提交信息，自动生成变更日志并发布新版本。
变更日志格式通常如下：
markdown
## [1.0.0] - 2025-11-25
### Added
- Added user login feature (`feat(auth)`)
### Fixed
- Fixed password reset issue (`fix(auth)`)
### BREAKING CHANGES
- Changed login API endpoint from `/login` to `/auth/login`3. Git 提交信息、版本号和变更日志的协作流程
在实际开发过程中，Git 提交信息、版本号和变更日志会形成一个紧密的自动化流程：
-
开发阶段 ：开发人员编写符合 Conventional Commits 规范的提交信息（例如，
feat、fix、BREAKING CHANGE）。 -
版本号管理 ：使用工具（如
semantic-release或standard-version）自动解析提交信息，根据语义版本控制规则，自动决定版本号的更新（主版本号、次版本号、修订号）。 -
生成变更日志：基于提交信息生成相应的变更日志，列出每个版本的新增功能、修复问题和破坏性更改。
-
发布过程：当新版本的发布需要上线时，自动生成的版本号和变更日志将作为发布说明的一部分，以便团队和用户了解本次发布的内容。
总结
- Git 提交信息 提供了对代码更改的详细描述，决定了版本号更新的依据。
- 版本号（特别是语义版本控制）用于标识每个发布的不同状态。
- 变更日志 记录了每个版本之间的差异，并通过 Git 提交信息自动生成，帮助团队和用户了解每个版本的内容。
通过使用规范化的 Git 提交信息和自动化工具，可以实现更高效的版本管理和发布流程，使得开发、测试、发布过程更加清晰、可控。
附录：Conventional Commits 规范
基本格式如下：
<type>(<scope>): <message>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>1. type (必选)
用来表示此次提交的目的。常见的 type 包括：
- feat: 新功能
- fix: 修复 bug
- docs: 文档修改
- style: 代码格式化（不影响功能的更改）
- refactor: 重构（即不修复 bug 也不添加功能的代码更改）
- perf: 性能优化
- test: 添加测试代码
- chore: 其它杂项修改（如构建过程、工具更新等）
2. scope (可选)
用来说明修改的范围。通常为模块名或功能名，帮助开发人员更容易理解修改的具体位置。比如：
feat(auth): add login featurefix(ui): button padding issue
3. message (必选)
简洁明了的描述此提交做了什么工作，采用祈使句形式，描述提交的目的或行为。建议使用小写字母，最多 72 个字符。
4. body (可选)
详细描述此次提交的内容、动机，或背景等。可以说明为什么需要做这个更改，以及做了什么具体的修改。若提交信息较复杂，建议提供一个详细的说明。
5. footer (可选)
用于标记与提交相关的额外信息。常见的用途包括：
- BREAKING CHANGE: 如果提交包含破坏性更改，可以在 footer 中标明，并简要描述此更改。
- Closes #issue_number: 关联到某个 issue，可以自动关闭相关 issue。
示例
bash
feat(auth): add user login feature
Added a new login page with email and password authentication.
This also includes validation for input fields and error handling.
BREAKING CHANGE: The login API endpoint has changed from /login to /auth/login.
Closes #42Git 提交消息规范化的其他工具
- Commitizen: 一个帮助团队遵循 commit 规范的工具，可以通过交互式提示生成符合规范的提交信息。
- standard-version: 通过 git 提交信息自动生成 changelog 和版本号。