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

后除發表於2024-04-25
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 這樣的圖形化客戶端時，可以清晰的看清專案的版本迭代記錄。

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 流程可以根據分支命名模式自動執行特定任務。

Workflows

案例專案：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

Git Commits

案例專案：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 的性質。

Merge Request and Pull Request

案例專案：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 的操作是透過建立一個新的提交來實現的，這個新提交是對舊提交的直接反轉，即他會引入與舊提交相反的變更。這樣做的好處是它不會改變專案歷史。

命令語法

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

（完）

相關文章