在實際中Git規範有哪些？

王铁柱6發表於2024-12-01
Git

前端開發中，實際應用的Git規範通常涵蓋以下幾個方面：

1. 分支管理策略:

  • 主分支 (main/master): 始終保持可部署狀態，只包含經過測試的穩定程式碼。通常用於釋出版本。避免直接在主分支上進行開發。
  • 開發分支 (develop): 整合分支，所有功能分支的程式碼最終都會合併到此分支。持續整合/持續部署 (CI/CD) 通常基於此分支構建。
  • 功能分支 (feature/{feature_name}): 用於開發新功能或修復特定bug。每個功能或bug都應該在一個獨立的功能分支上進行開發。分支名稱應該簡潔明瞭地描述功能或bug。
  • 釋出分支 (release/{version_number}): 用於準備釋出新版本。從 develop 分支建立，進行最後的測試和版本號的確定。
  • 熱修復分支 (hotfix/{issue_number}): 用於緊急修復生產環境中的嚴重bug。從 main/master 分支建立，修復完成後合併回 main/master 和 develop 分支。

2. 提交資訊規範:

  • 格式: <type>(<scope>): <subject>
    • type: 提交型別，例如 feat (新功能), fix (bug修復), docs (文件更新), style (程式碼風格調整), refactor (程式碼重構), test (測試), chore (構建任務或輔助工具的修改), perf (效能最佳化), revert (程式碼回滾)。
    • scope: 可選，提交影響的範圍，例如模組名、元件名等。
    • subject: 簡短的提交描述，不超過50個字元。首字母大寫，不以句號結尾。
  • 正文: 可選，更詳細的提交說明，解釋修改的原因和具體內容。
  • 頁尾: 可選，關聯issue編號，例如 Closes #123。

示例:

feat(login): add login validation

Added input validation for the login form to prevent empty submissions.

Closes #123

3. 程式碼審查 (Code Review):

  • 提交程式碼前進行自測，確保程式碼質量。
  • 提交程式碼後，建立 Pull Request (PR) 並指定至少一名 Reviewer 進行程式碼審查。
  • Reviewer 仔細檢查程式碼，提出修改建議。
  • 程式碼作者根據 Reviewer 的建議進行修改，並再次提交審查。
  • 程式碼審查透過後，合併程式碼到目標分支。

4. 其他規範:

  • .gitignore 檔案: 配置需要忽略的檔案和目錄，例如構建產物、臨時檔案、敏感資訊等。
  • 避擴音交過大的檔案: 大檔案會影響倉庫的效能，應該使用 Git LFS (Large File Storage) 等工具來管理。
  • 定期清理無用分支: 刪除已合併或廢棄的分支，保持倉庫的整潔。
  • 使用合適的工具: 例如 SourceTree, GitKraken 等視覺化工具可以簡化 Git 操作。

前端開發特有的考慮:

  • 提交構建後的程式碼: 是否提交dist或build目錄下的程式碼取決於專案和團隊的具體情況。一些團隊選擇提交構建後的程式碼以便快速部署，而另一些團隊則選擇在部署過程中進行構建以減少倉庫大小。需要根據實際情況進行權衡。
  • package-lock.json 或 yarn.lock: 始終提交這些檔案，以確保團隊成員使用相同的依賴版本。

遵循這些規範可以提高團隊協作效率，保證程式碼質量，並方便專案的維護和管理。 記住，規範的目的是為了更好地服務於開發流程，可以根據團隊的實際情況進行調整和最佳化。

相關文章