開發者們大家好，我將分享一些更有效地使用 Git 的最佳實踐。Git？是的，就是你已經熟悉的 git。程式碼夥伴是您的守護天使，可確保您的程式設計冒險順利進行，讓開發人員能夠輕鬆地進行專案協作。
你是那個建立分支然後忘記它們存在的原因的人嗎？總是需要尋找文件變更才能理解提交？這裡有一些建議供您參考。
我為什麼要遵循標準？
-
清晰和理解
-
協作與團隊合作
-
易於導航和維護
-
文件和知識轉移
-
工程品質
-
自動化變更日誌
-
優化 CI/CD
在你讀之前
-
分支命名約定和提交訊息約定下的每個 seb 部分分別按基本、中階和進階規則排序。
-
您可以根據用例和相關性遵循任何層級的規則，無論如何，建議遵循中間規則層級的約定。
-
以下內容根據參考部分提供的資源進行改編和組織。
分支命名約定
基本
- 描述性名稱：一個命名良好的分支可以為其目的提供直接的上下文。選擇清晰的名稱，而不是通用名稱。
例如： feature/login 、 bugfix/navbar-overflow
- 使用連字號：使用連字號分隔分支名稱中的單字（或短橫線），這確保了可讀性。
例如， bugfix/fix-login-issue比bugfix/fixLoginIssue或bugfix/fix_login_issue更具可讀性。
-
小寫字母數字字元：僅使用小寫字母數字字元（az、0–9）和連字號。盡可能避免標點符號、空格、底線或任何特殊字元。
-
避免不必要的連字符：避免不必要的連字符，例如後續或尾隨的連字符。
例如， feat/new--login-是一種不好的做法。
- 簡短有效：保持分支名稱簡單。在描述性的同時，它們也應該足夠簡潔，以便一目了然地傳達目標。
前綴或類型
-
為分支加入前綴有助於根據其用途來組織它們。這不僅提高了清晰度，還有助於自動化工作流程。
-
一些常見的分支類型前綴及其用例包括：
-
feature/：用於開發新功能， -
bugfix/：修復程式碼中的錯誤。通常是與某個問題相關的。 -
hotfix/：修復生產中的關鍵錯誤。 -
release/：準備新版本，通常用於執行最後修改和修訂等任務。 -
docs/：用於撰寫、修改或修正文件。 -
例如，
feature/new-feature或release/version-1.0.0。
包括票號
如果您的專案使用 Jira 等問題追蹤系統，或者它根據 github 問題或其他類似工具進行修改。在分支名稱中包含問題的令牌將使追蹤變得簡單。範例： feature/PROJ-123-footer-links
提交訊息約定
- 提交訊息的最終格式：
<type>([optional scope]): <description> # subject
[optional body]
[optional footer(s)]資訊主題
- 命令式：以命令式建立提交訊息。以動詞開頭來指示提交的作用。
例如：使用fix: Fix bug #67比fix: Fixed bug #67
-
簡短總結：嘗試將主題行控制在 50 個字元以內，以確保訊息在各種 Git 工具中可讀，例如使用
git log --oneline時。避免尾隨句點和不必要的單字/符號。 -
將描述大寫：這聽起來很簡單。主題行以大寫字母開頭。
類型和訊息正文
-
主題行中的
type前綴可用於表示提交中包含的變更的類型。一些常用的類型是： -
feat:：總結程式碼庫中的新功能。 -
fix:：修復程式碼庫。 -
build:、chore:、ci:、style:、refactor:是其他一些例子。 -
可以將
scope加入到提交的類型中以提供額外的上下文訊息，並將其括在括號中，例如feat(parser): Add the ability to parse arrays -
可以將
body新增至訊息中，以在提交中包含詳細說明。 -
在主題行後面留空行來加入正文。
-
將正文包裹在 72 個字元處，即。使用多行正文，每行不超過 72 個字元。
頁腳和擴充訊息正文
-
footer用於傳達有關提交的附加訊息，例如審查者、批准者等。例如： -
Signed-off-by: Alice <[email protected]> -
重大變更：
BREAKING CHANGE是指程式碼庫中相當重要的重大變更。可以透過加!來表示。在類型/範圍之後和/或透過將其加入到body或作為footer
chore!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.- 多段落正文：在某些情況下，多個段落有助於更詳細地解釋提交的目標。範例：描述提交更改的內容、原因以及方式。
例子
可以在此處找到提交訊息的各種用例範例。
結論
遵守 Git 約定類似於說通用語言。然而，很明顯，這些標準或約定並沒有被任何系統強制執行；因此，這些標準的調整和擴展使用完全取決於我們。
養成這些習慣肯定會改善您的 Git 體驗並鼓勵協作編碼環境。儘管我們不能一下子就遵循這些，但逐漸適應它們無疑會有所不同。
我計劃寫一篇關於使用 Husky 實現 Git 約定的文章，透過反應和評論來表達您的支持。快樂編碼！
參考
原文出處：https://dev.to/shinjithdev/git-good-best-practices-for-branch-naming-and-commit-messages-oj4
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式