爲什麼需要Git規範？¶
在沒有規範的團隊協作中，Git版本控制常常會變成“一團亂麻”：有人隨便創建分支，有人提交信息寫得含糊不清，代碼合併時各種衝突，想找一個歷史版本修復bug卻要翻遍所有提交記錄……結果就是效率低下，協作混亂。
而統一的Git規範，就像團隊協作的“交通規則”，能讓每個人的操作清晰可預測，減少溝通成本，方便代碼追蹤和問題定位。接下來，我們就從最基礎的“分支命名”和“提交信息”入手，一步步建立團隊協作的Git規範。
一、分支命名規範：給每個分支“貼標籤”¶
分支是Git的核心功能，規範分支命名能讓所有人快速知道：這個分支是做什麼的？從哪裏來？要到哪裏去？
1. 常見分支類型（團隊協作中必備）¶
- 主分支（Master/Main）：項目的“源頭”，保持絕對穩定，只接受合併，不直接在上面寫代碼。通常對應生產環境，一旦發佈就不再修改。
- 開發分支（Develop）：集成開發中的功能，所有功能完成後會合併到這裏，用於測試和預發佈。
- 功能分支（Feature）：爲新功能或大需求創建的分支，從Develop分支分出，完成後合併回Develop。
- 修復分支（Bugfix）：修復開發中發現的bug，從Develop分支分出，修復後合併回Develop。
- 熱修復分支（Hotfix）：生產環境緊急bug的修復，從Master分支分出，修復後同時合併到Master和Develop。
2. 命名格式（團隊必須統一）¶
- Feature分支：
feature/[需求ID]-[功能簡述]
例：feature/123-user-login-form（需求ID123，功能是用戶登錄表單） - Bugfix分支：
bugfix/[bugID]-[bug簡述]
例：bugfix/456-fix-login-validation（bugID456，修復登錄驗證問題） - Hotfix分支：
hotfix/[bugID]-[問題簡述]
例：hotfix/789-fix-payment-crash（修復生產支付崩潰問題） - 主分支和開發分支：通常固定名稱（Master/Main、Develop），不需要額外命名規則。
小技巧：¶
- 分支名稱儘量簡潔，但要包含關鍵信息（如需求ID/問題ID），方便用工具（如GitLab/GitHub）搜索。
- 避免中文和特殊符號（如
#、$），防止不同系統識別問題。
二、提交信息規範：讓每次“提交”都有意義¶
提交信息是代碼的“說明書”，好的提交信息能幫你（和隊友）快速定位：這次改了什麼？爲什麼改？
1. 爲什麼要規範提交信息？¶
- 避免“一堆亂改”：別人（或未來的你）看提交記錄時，能一眼知道某次修改的目的。
- 方便版本管理：用工具（如Git log）篩選特定類型的提交（比如只看“fix”相關的）。
- 自動化工具支持：符合規範的提交信息能被自動生成變更日誌（如Changelog）。
2. 最常用的“約定式提交”規範¶
格式：類型: 簡短主題（不超過50字）[可選：詳細描述]
類型（必選）：¶
- feat：新功能（比如添加用戶註冊、首頁輪播）
- fix：修復bug（比如“用戶登錄後閃退”“按鈕點擊沒反應”）
- docs：文檔更新（比如README、API註釋修改）
- style：代碼格式調整（如縮進、空格，不影響邏輯）
- refactor：代碼重構（比如優化函數邏輯，但不新增功能/修bug）
- perf：性能優化（如減少加載時間、提升查詢速度）
- test：測試相關（比如新增單元測試、修復測試用例）
- chore：日常任務（如依賴更新、版本號修改、清理臨時文件）
示例：¶
- ✅ 規範寫法：
feat: add user registration form
（新功能：添加用戶註冊表單） - ✅ 規範寫法：
fix: resolve login button unresponsive issue
（修復：解決登錄按鈕無響應問題） - ✅ 帶詳細描述：
docs: update API documentation
（詳細：更新用戶手冊中“獲取token”的步驟） - ❌ 不規範寫法：
改了點東西（別人完全看不懂）
3. 如何記住規範？¶
- 類型首字母小寫：
fix而非Fix（養成習慣更統一）。 - 主題簡潔明瞭：用祈使句（如“add”而非“added”）。
- 描述換行：詳細描述用空行隔開，寫在主題下面，方便閱讀。
三、規範落地：常用Git命令輔助操作¶
1. 創建分支（按規範）¶
# 先確保開發分支是最新的
git checkout develop
git pull origin develop
# 創建功能分支（示例：需求ID123，功能“用戶登錄表單”）
git checkout -b feature/123-user-login-form
2. 提交代碼（按規範）¶
# 查看已修改文件
git status
# 添加所有修改（或指定文件）
git add . # 添加所有新增/修改文件
# 提交（示例：添加用戶登錄表單）
git commit -m "feat: add user registration form"
# 推送分支到遠程
git push origin feature/123-user-login-form
3. 合併到開發分支（協作時）¶
# 切換到develop分支並拉取最新代碼
git checkout develop
git pull origin develop
# 合併功能分支
git merge feature/123-user-login-form
# （可選）刪除已合併的分支
git branch -d feature/123-user-login-form
4. 處理衝突（規範落地關鍵點）¶
如果合併時出現衝突，不要慌！按以下步驟解決：
1. 拉取最新代碼：確保本地develop分支是最新的。
2. 手動修改衝突文件：打開衝突文件（Git會標記衝突區域，如<<<<<<< HEAD）。
3. 協商解決：和相關隊友溝通，確定最終代碼邏輯。
4. 標記衝突已解決：
git add . # 所有衝突文件解決後執行
git commit -m "merge: resolve conflicts in login form"
四、如何讓團隊嚴格遵守規範？¶
- 代碼審查時強調：合併前檢查分支命名和提交信息是否合規。
- 使用工具輔助：
- 用pre-commit鉤子自動檢查提交信息（比如要求必須包含feat/fix）。
- 在GitHub/GitLab的PR模板中明確規範要求。 - 形成團隊共識：新人入職時講解規範，定期回顧（比如每週10分鐘）。
總結¶
Git規範的核心是“清晰可追蹤”：分支命名讓協作目標明確，提交信息讓修改目的透明。剛開始可能覺得麻煩，但養成習慣後，代碼會變得像“有索引的賬本”——任何問題都能快速定位到源頭，團隊協作效率自然提升。
從今天開始，試試用規範的分支命名和提交信息寫第一行代碼吧！