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 提交信息，自動生成變更日誌併發布新版本。
變更日誌格式通常如下：
## [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 規範
基本格式如下：
():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。
示例
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 和版本號。
