在 Git 和代碼審查工具（如 Gerrit）中，Commit 號（Commit Hash） 和 Change-Id 號 是兩個不同的概念，它們在代碼管理和協作中扮演不同的角色。以下是它們的區別與聯系。

1、Commit 號

Commit 號（Commit Hash）

定義：

• Commit 號是 Git 為每次提交生成的唯一標識符，由 SHA-1 算法計算得出（通常為 40 個十六進制字符，如 abc1234…）。

作用：

• 唯一標識一次提交。
• 用于在 Git 倉庫中定位、比較或回滾到特定提交。

特點：

• 完全由提交內容（包括代碼、提交信息、父提交等）決定，內容變更則哈希值變化。
• 全局唯一（同一倉庫或不同倉庫中，內容相同的提交哈希值相同）。

示例：

git log -1  # 查看最新提交的哈希值

2、Change-Id 號

定義：

• Change-Id 是代碼審查工具（如 Gerrit）為每次代碼變更（Change）生成的唯一標識符，通常為 I 開頭的字符串（如 Iabc1234…）。

作用：

• 唯一標識一次代碼變更（可能包含多次提交）。
• 用于在代碼審查流程中跟蹤變更的修訂歷史（如提交補丁、修復評審意見等）。

特點：

• 由開發者在提交信息中顯式添加（或通過工具自動生成），通常格式為：
  Change-Id: Iabc12345678901234567890123456789012345678

• 即使提交內容變更（如修復評審意見后重新提交），只要變更的邏輯相同，Change-Id 保持不變。

示例在提交信息中添加 Change-Id：

git commit -m "Fix bug" -m "Change-Id: Iabc12345678901234567890123456789012345678"

3、區別與聯系

聯系：

• 一對多關系：一個 Change-Id 可能對應多個 Commit 號（如修復評審意見后重新提交）。
• 共同用于代碼管理：Commit 號用于 Git 操作，Change-Id 用于代碼審查流程。

4、實際場景示例

1）開發者提交代碼

提交信息中包含 Change-Id 或者 git 提交時自動生成：

git commit -m "Add feature" -m "Change-Id: Iabc12345678901234567890123456789012345678"

Git 生成 Commit 號（如 abc123）。

2）代碼審查流程

評審者提出修改意見，開發者修復后重新提交（Change-Id 不變，Commit 號變化）。

Gerrit 通過 Change-Id 關聯兩次提交，視為同一次變更的不同修訂版本。

3）合并到主分支

評審通過后，代碼變更（包含多次提交）被合并到主分支，Change-Id 完成使命，后續僅通過 Commit 號跟蹤 Git 歷史。

5、為什么需要兩者？

• Commit 號：Git 的核心機制，用于版本控制和歷史追蹤。

• Change-Id：代碼審查工具的擴展機制，用于跟蹤變更的修訂歷史（尤其在多人協作、長期評審的場景中）。

6、總結

Commit 號：Git 的“身份證”，唯一標識一次提交。

Change-Id 號：代碼審查工具的“跟蹤號”，唯一標識一次代碼變更（可能包含多次提交）。

兩者結合：既滿足 Git 的版本控制需求，又支持代碼審查流程中的變更跟蹤。

理解兩者的區別與聯系，有助于更高效地使用 Git 和代碼審查工具（如 Gerrit）。

附錄——Gerrit

Gerrit 是一個基于 Git 的開源代碼審查工具，主要用于管理開發人員對代碼的提交和審查流程，旨在提升代碼質量和團隊協作效率。以下是關于 Gerrit 的詳細介紹：

（1）核心功能

代碼審查：

• 開發人員提交代碼變更后，不會直接合并到目標分支，而是先進入審查流程。
• 審查者可以通過 Web 界面逐行查看代碼變更，提出修改建議或直接批準合并。
• 支持多人協作審查，促進知識共享和問題發現。

權限管理：

• 提供細致的權限控制機制，可針對用戶或用戶組設置不同的訪問權限。
• 權限包括提交、審查、推送等操作，確保團隊成員只能訪問其職責范圍內的內容。

補丁集管理：

• 支持將多個相關的更改打包成一個補丁集進行處理，便于管理和審查復雜的代碼變更。

集成與擴展：

• 提供豐富的觸發器和插件機制，可與 Jenkins、Travis CI 等工具集成，實現自動化構建和測試。
• 提供 RESTful API，方便開發者通過編程方式與 Gerrit 交互，實現自定義工作流程。

（2）工作流程

開發者提交代碼：

• 開發者在本地編寫代碼后，通過 git push 將變更推送到 Gerrit 服務器。
• 提交時需包含 Change-Id，用于標識同一次代碼變更的不同修訂版本。

代碼審查：

• 審查者收到通知后，在 Gerrit 的 Web 界面查看代碼變更，提出評論或評分。
• 評分通常為 -2（拒絕）、-1（不推薦）、0（無意見）、1（推薦）、2（批準）。

返工與重新提交：

• 如果代碼未通過審查，開發者需根據反饋修改代碼，并通過 git commit --amend 更新提交信息。
• 重新推送時，Change-Id 保持不變，但補丁集版本號會增加。

合并到主分支：

• 代碼通過審查后，可被合并到目標分支，正式進入項目代碼庫。

（3）優勢

提高代碼質量：

• 通過嚴格的審查流程，確保只有經過驗證的代碼才能合并到主分支，減少錯誤和漏洞。

促進團隊協作：

• 提供平臺讓開發者和審查者實時交流，增強團隊溝通與協作。

靈活的權限管理：

• 可根據項目需求定制權限，滿足不同團隊和項目的管理需求。

可擴展性強：

• 通過插件機制，可輕松與其他工具和服務集成，擴展功能和應用場景。

（4）適用場景

大型開源項目：如 Linux 內核、Android 等，Gerrit 的高效審查流程和權限控制機制為龐大開發者社區和復雜代碼庫提供支持。

企業級應用：通過集成 Jenkins 等持續集成工具，實現自動化構建和測試，提高開發效率和代碼質量。

教育領域：作為教學工具，幫助學生了解軟件開發流程和代碼審查的重要性。

（5）使用建議

熟悉 Git 操作：

• Gerrit 基于 Git，使用前需掌握 Git 的基本命令和工作流程。

配置 SSH 密鑰：

• 為確保安全，建議通過 SSH 協議與 Gerrit 交互，需提前配置 SSH 密鑰。

遵循審查規范：

• 提交代碼時，確保提交信息清晰，包含 Change-Id，便于審查者理解變更內容。

積極參與審查：

• 作為團隊一員，積極參與代碼審查，提出建設性意見，共同提升代碼質量。