如果您是開發人員，您可能每天都會使用名為 Git 的版本控制系統。無論是團隊工作還是個人工作，該工具的使用對於應用程式的開發過程都至關重要。然而，通常會遇到混亂的儲存庫、提交的訊息不明確、無法傳達有用資訊以及濫用分支等問題。對於想要在就業市場中脫穎而出的人來說，了解如何正確使用 Git 並遵循良好實踐至關重要。

目錄

1. Git 分支的命名約定

2. 分支名稱約定前綴

3. 提交訊息

4. 常規提交

Git 分支的命名約定

當我們使用程式碼版本控制時，我們應該遵循的主要良好實踐之一是為分支、提交、拉取請求等使用清晰且描述性的名稱。確保所有團隊成員的簡潔工作流程至關重要。除了提高生產力之外，記錄專案的開發過程還可以簡化團隊合作。透過遵循這些做法，您很快就會看到好處。

基於此，社群建立了一個您可以在專案中遵循的分支命名約定。以下專案的使用是可選的，但它們可以幫助提高您的開發技能。

1.小寫：分支名稱不要使用大寫字母，堅持小寫；

2. 連字符分隔：如果您的分支名稱由多個單字組成，請用連字符分隔它們。遵循烤肉串慣例。避免 PascalCase、camelCase 或 Snake_case；

3. (az, 0-9)：分支名稱中僅使用字母數字字元和連字符。避免使用任何非字母數字字元；

4. 請不要使用連續的連字號（--）。這種做法可能會令人困惑。例如，如果您有分支類型（例如功能、錯誤修復、修補程式等），請改用斜線 (/)；

5. 避免以連字符結尾分支名稱。這是沒有意義的，因為連字符分隔單詞，並且末尾沒有單詞可以分隔；

6. 這個做法最重要：使用描述性的、簡潔的、清晰的名稱來解釋分支上做了什麼；

分支名稱錯誤

• fixSidebar

• feature-new-sidebar-

• FeatureNewSidebar

• feat_add_sidebar

好聽的支行名字

• 功能/新側邊欄

• 新增側邊欄

• 修補程式/取得歷史資料上的間隔查詢參數

分支名稱約定前綴

有時分支的目的並不明確。它可以是新功能、錯誤修復、文件更新或其他任何內容。為了解決這個問題，通常的做法是在分支名稱上使用前綴來快速解釋分支的用途。

• feature：它傳達了將要開發的新功能。例如， feature/add-filters ；

• 發布：用於準備新版本。前綴release/通常用於在合併來自分支主伺服器的新更新以建立版本之前執行諸如上次觸及和修訂之類的任務。例如， release/v3.3.1-beta ；

• bugfix：它表示您正在解決程式碼中的錯誤，並且它通常與問題相關。例如， bugfix/sign-in-flow ；

• hotfix：與bugfix類似，但它與修復生產環境中存在的嚴重錯誤有關。例如， hotfix/cors-error ；

• docs：寫一些文件。例如， docs/quick-start ；

如果您正在使用任務管理工作流程，例如 Jira、Trello、ClickUp 或任何可以建立使用者故事的類似工具，則每張卡片都有一個關聯的編號。因此，通常在分行名稱的前綴上使用這些卡號。例如：

• feature/T-531-add-sidebar

• docs/T-789-update-readme

• hotfix/T-142-security-path

提交訊息

讓我們來談談提交訊息。不幸的是，很容易找到帶有“加入了很多東西”或“皮卡丘，我選擇你”之類的提交訊息的專案......是的，我曾經發現一個專案，其中提交訊息與神奇寶貝戰鬥有關。

提交訊息在開發過程中非常重要。創造一段美好的歷史將在你的旅程中給你很多幫助。與分支一樣，提交也有社區建立的約定，您可以在下面了解：

• 提交訊息包含三個重要部分：主題、說明和頁腳。提交的主題是必要的，它定義了提交的目的。描述（正文）用於為提交的目的提供額外的上下文和解釋。最後是頁腳，通常用於元資料，例如分配提交。雖然同時使用描述和頁腳被認為是一種很好的做法，但這不是必需的。

• 在主題行中使用祈使語氣。例如：

Add README.md ✅;

Added README.md ❌；

Adding README.md ❌；

• 主題行的第一個字母大寫。例如：

Add user authentication ✅；

add user authentication ❌；

• 不要以句號結束主題行。例如：

Update unit tests ✅；

Update unit tests. ❌;

• 主題行限制在50個字元以內，即清晰、簡潔；

• 將正文包裹在72 個字元處，並將主題與空白行分隔開；

• 如果您的提交正文有多個段落，請使用空白行將它們分開；

• 如有必要，使用要點而不是僅使用段落；

常規提交

“常規提交規範是基於提交訊息的輕量級約定。它提供了一組簡單的規則來建立明確提交歷史記錄。”

以下引用來自Conventional Commit 的官方網站。該規範是社區中提交訊息最常使用的約定。

結構

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

提交類型

我們要研究的第一個結構是提交類型。它提供了有關此提交中所做操作的清晰上下文。您可以在下面看到提交類型清單以及何時使用它們：

• feat：引進新功能；

• fix：修復軟體錯誤；

• refactor：用於程式碼更改，保留其整體功能；

• chore：不影響生產程式碼的更新，涉及工具、配置或程式庫調整；

• docs：文件文件的新增或修改；

• perf：程式碼更改提高效能；

• style：與程式碼呈現相關的調整，例如格式和空白；

• test：測試的包含或修正；

• build：影響建置系統或外部依賴項的修改；

• ci： CI 設定檔和腳本的更改；

• env：描述 CI 流程中設定檔的調整或加入，例如容器配置參數。

範圍

範圍是一種結構，可以在提交類型之後加入以提供額外的上下文資訊：

• fix(ui): resolve issue with button alignment

• feat(auth): implement user authentication

身體

提交訊息的正文提供了提交引入的更改的詳細說明。它通常會加入在主題行後面的空白行之後。

例子：

Add new functionality to handle user authentication.

This commit introduces a new module to manage user authentication. It includes
functions for user login, registration, and password recovery.

頁尾

提交訊息的頁腳用於提供與提交相關的附加資訊。這可以包括諸如誰審查或批准了變更之類的詳細資訊。

例子：

Signed-off-by: John <[email protected]>
Reviewed-by: Anthony <[email protected]>

突破性變革

指示提交包含可能導致相容性問題或需要修改相關程式碼的重大變更。您可以在頁腳中新增BREAKING CHANGE或包含!在類型/範圍之後。

使用常規提交的提交範例

chore: add commitlint and husky
chore(eslint): enforce the use of double quotes in JSX
refactor: type refactoring
feat: add axios and data handling
feat(page/home): create next routing
chore!: drop support for Node 18

包含主題、正文和頁尾：

feat: add function to convert colors in hexadecimal to rgba

Lorem Ipsum is simply dummy text of the printing and typesetting industry.

Lorem Ipsum has been the industry's standard dummy text ever since the 1500s.

Reviewed-by: 2
Refs: #345

參考

• https://www.conventionalcommits.org

• https://medium.com/@abhay.pixolo/naming-conventions-for-git-branches-a-cheatsheet-8549feca2534

• https://se-education.org/guides/conventions/git.html

• https://cbea.ms/git-commit/

https://blog.geekhunter.com.br/o-que-e-commit-e-como-usar-commits-semanticos/

原文出處：https://dev.to/anthonyvii/be-a-better-developer-with-these-git-good-practices-2dim