Git 版本控制：構建高效協作和開發流程的最佳實踐

引言

版本控制是開發中不可或缺的一部分，他允許多人同時協作，通過記錄每一次代碼的變更，幫助開發者理解何時、爲什麼以及誰做了修改。這不僅有助於錯誤追蹤和功能回溯，還使得團隊能夠並行工作，通過分支管理實現功能的增加和問題的修復。此外，也允許開發者在出現問題時回滾到之前的狀態，確保項目的穩定發展。

1. 分支命名策略

主要分支命名

• main 或 master：項目的主分支，存放正式發佈的版本。
• develop：開發分支，用於日常開發階段驗證新功能，此分支不會推送至生產環境；且由於髒代碼的堆積，偶爾需要重建下。

功能性分支命名

以一種結構化的方法命名，如<類型>/<版本>/<描述>，例如：fix/v1.0.0/authentication。這裏的版本可根據實際情況決定，可以是 v1.0.0，也可以是 v1.0、v1、1.0.0 等。

• feature/<版本>/<功能>：用於開發新功能的分支，例如：feature/v1.0.0/authentication。
• fix/<版本>/<問題描述>：修復特定版本中的錯誤，例如：fix/v1.0.0/login。

其他類型名：docs、refactor、test 等。

這樣命名的好處是，面對 SourceTree 這樣的圖形化客戶端時，可以清晰的看清項目的版本迭代記錄。

注：由於不同的規範和風格，這裏的分隔符也常使用下劃線，例如：feature_v1.0.0_authentication。

特定目的或臨時性分支命名

• release/<版本>：用於準備發佈的版本，允許進行最後的調整，例如：release/v1.0.0。
• hotfix/<版本>/<問題描述>：用於緊急修復生產環境中的問題，例如：hotfix/v1.0.0/payment。

個人或團隊工作分支命名

• <用戶>/<類型>/<版本>/<描述>：個人工作分支，明確指出負責人和工作內容，例如：john/fix/v1.0.0/login-issue。
• team/<團隊>/<類型>/<版本>/<描述>：團隊工作分支，有助於區分不同團隊的工作，例如：team/account/feature/v1.0.0/add-nickname。

分支命名策略的重要性

1. 清晰性：良好的命名策略可以快速告訴其他人這個分支的目的和內容。
2. 組織性：有助於在大型項目中管理和維護衆多的分支。
3. 自動化：一些自動化工具和 CI/CD 流程可以根據分支命名模式自動執行特定任務。

案例項目：https://github.com/mazeyqian/mazey/actions

2. 代碼提交規範

一個良好的提交信息能夠讓其他人快速理解這次提交的目的，以及它對項目產生的影響。以下是一個推薦的代碼提交規範格式：

<type>(<scope>): <subject>

• <type>：提交類型，用於說明 Commit 的類別，比如是修復 Bug（fix）、添加新功能（feature）還是文檔變更（docs）等；
• <scope>：影響範圍，可選項，用於指明本次提交影響的範圍或模塊，例如：login、userModel、docs 等；
• <subject>：簡短描述，具體說明本次提交的主要內容，應簡潔明瞭。

類型（type）

常見的提交類型包括：

• feat：新增功能（feature）；
• fix：修補 Bug；
• docs：文檔變更；
• style： 格式（不影響代碼運行的變動）；
• refactor：重構（即不是新增功能，也不是修改 Bug 的代碼變動）；
• test：增加測試；
• chore：構建過程或輔助工具的變動。

主題（subject）

主題是對 Commit 目的的簡短描述，不超過 50 個字符，建議使用現在時態和小寫字母，並且不以句號結尾，例如：

• feat(login): add captcha to login form
• fix(userModel): correct age calculation logic
• docs(readme): update installation instructions

案例項目：https://github.com/mazeyqian/mazey

3. Merge Request（MR）的實踐

Merge Request（MR）或 Pull Request（PR）是代碼審查和合並的重要環節。它不僅涉及代碼的合併，還可以幫助團隊成員之間進行溝通、提供反饋和確保代碼質量。

清晰明確的標題

• 明確模塊或功能：如果可能，指明 MR 影響的具體模塊或功能，使得標題更加具體，例如：feat(user): 添加用戶登錄功能 或 fix(database): 解決併發訪問時的數據不一致問題。
• 關聯 Issue：如果 MR 與特定的 Issue 相關，可以在標題中直接提及該 Issue，例如使用 Close #1 表示此次 MR 旨在解決編號爲 1 的 Issue。這不僅能夠提供更多上下文信息，還可以在某些平臺上自動關閉相關的 Issue。
• 使用標籤：在標題中使用標籤（例如：feat、fix、docs 等）來標明 MR 的類型，這有助於快速瞭解 MR 的性質。

案例項目：https://github.com/tzfqh/gmdtable

詳細的描述

對 MR 進行詳細說明的部分，應該包含所有必要的信息，以便理解這次提交的背景、目的和具體實現。

• 背景和目的：首先簡要說明爲什麼需要這次改動，他解決了什麼問題或帶來了哪些新功能。
• 完成的任務清單：提供一個清單，列出了此次 MR 完成了哪些具體任務。這有助於跟蹤 MR 的進度和範圍。
• 變更說明：詳細描述代碼變更的內容，包括新增、修改或刪除了哪些功能或模塊。
• 測試和驗證：說明已經進行了哪些測試或驗證步驟來確保代碼的質量和功能的正確性。
• 額外信息：如有必要，可以添加如何配置新功能、影響的用戶或系統部分、未來規劃等額外信息。

例如：

Title: feat(login): 添加驗證碼功能 (Close #1)

Description:

實現了在用戶登錄流程中添加驗證碼功能，旨在增強系統安全性。

已完成的任務：

- 設計並實現驗證碼生成邏輯
- 在登錄表單中集成驗證碼輸入字段
- 實現驗證碼驗證邏輯
- 更新相關文檔和測試用例

此次改動通過了所有單元測試，並在本地環境中進行了手動測試驗證，確保新加入的驗證碼功能正常工作。

關聯 Issue：#1

4. 打標籤

打標籤（Tagging）是一種標記特定版本的方法，他允許在項目的歷史中快速定位到某個點。

打輕量標籤

輕量標籤（Lightweight Tag）是指向某個提交對象的引用，他就像一個不會改變的分支。創建輕量標籤不會存儲額外的信息（如標籤創建者、郵箱、創建日期等）。如果只是爲了快速記住某個提交點，可以使用輕量標籤。

git tag <tagname> <commit-hash>

• <tagname>：想要創建的標籤名稱；
• <commit-hash>：（可選）想要標記的提交的哈希值。如果省略，Git 會在當前提交上創建標籤。

示例：

git tag v1.0.0 abc1234

打註釋標籤

註釋標籤（Annotated Tag）會存儲額外的信息，比如創建者的名字、電子郵件地址、日期和標籤信息。

git tag -a <tagname> -m "<tagmessage>" <commit-hash>

• -a：表示創建一個註釋標籤；
• <tagname>：想要創建的標籤名稱；
• -m：後面跟隨的是這個標籤的信息；
• <tagmessage>：標籤信息，簡短描述這個標籤；
• <commit-hash>：（可選）你想要標記的提交的哈希值。

示例：

git tag -a v1.0.1 -m "Release version 1.0.1 with minor bug fixes" abc1234

推送標籤到遠程倉庫

默認情況下，git push 命令不會將標籤推送到遠程倉庫，需要顯式地推送標籤。

推送特定標籤：

git push origin <tagname>

示例：

git push origin v1.0.0

推送所有本地標籤：

git push origin --tags

5. 遇到問題使用 git revert 回滾

git revert 是用於撤銷之前提交的變更的命令，git revert 的操作是通過創建一個新的提交來實現的，這個新提交是對舊提交的直接反轉，即他會引入與舊提交相反的變更。這樣做的好處是它不會改變項目歷史。

命令語法

git revert <commit-hash>

這裏 <commit-hash> 是你想要撤銷的提交的哈希值。

操作流程

• 找到你想要撤銷的提交的哈希值，可以通過 git log 查看提交歷史；
• 執行 git revert 命令並指定相應的哈希值；
• Git 會創建一個新的提交，這個提交會撤銷指定提交所做的所有變更；
• 如果有衝突，解決完衝突才能完成 revert 操作。

使用場景

git revert 是在不打亂項目歷史的情況下撤銷變更的安全方式。例如，如果一個已經發布到生產環境中的提交引入了一個嚴重錯誤，使用 git revert 可以快速地撤銷這個提交帶來的影響，同時保留了完整的項目歷史。

與 git reset 的區別

git reset 也可以用來撤銷變更，但他通過移動分支指針到舊的提交來實現，這會改變項目歷史。

總結

版本控制是軟件開發的核心，促進團隊協作與項目管理。通過制定明確的分支命名策略（例如：main、develop、feature/<版本>/<功能> 等），遵循一致的代碼提交規範，如指明提交類型和簡短描述，增強了歷史記錄的可讀性，可以清晰地組織和理解項目的結構與進展。

版權聲明

本博客所有的原創文章，作者皆保留版權。轉載必須包含本聲明，保持本文完整，並以超鏈接形式註明作者後除和本文原始地址：https://blog.mazey.net/4581.html

（完）