GIT好習慣助你成為更出色的開發者

發表於2024-02-19
Git
本文翻譯自 Be a better developer with these Git good practices，作者：Anthony Vinicius， 略有刪改。

如果你是一名開發人員，你可能每天都在使用Git版本控制系統。無論是在團隊中還是單獨工作，使用此工具對於程式的開發過程都很重要。但在實際工作中卻經常遇到提交不明確的訊息，沒有傳達有用的資訊，以及濫用分支等問題。瞭解如何正確使用Git並遵循良好的實踐對於那些想要在工作中脫穎而出的人來說至關重要。

Git分支的基本約定

當我們使用程式碼版本控制時，我們應該遵循的主要良好實踐之一是為分支、提交、拉取請求等使用清晰和描述性的名稱。除了提高生產力之外，記錄專案的開發過程，簡化了團隊溝通協作。透過遵循這些做法，你很快就會看到好處。

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

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

2.連字元分隔：如果您的分支名稱由多個單片語成，請用連字元分隔。避免PascalCase、camelCase或snake_case;

3. (a-z，0-9）：在分支名稱中僅使用字母數字字元和連字元。避免任何非字母數字字元;

4.請不要使用連續的連字元（--）。這種做法可能令人困惑。如果您有分支型別（如功能、錯誤修復、熱修復等），使用斜槓（/）代替;

5.避免以連字元結束分支名稱。這是沒有意義的，因為連字元分隔單詞，沒有單詞在最後分開;

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

❎ 錯誤的分支名稱

  • fixSidebar
  • feature-new-sidebar-
  • FeatureNewSidebar
  • feat_add_sidebar

✅ 好的分支名稱

  • feature/new-sidebar
  • add-new-sidebar
  • hotfix/interval-query-param-on-get-historical-data

分支名稱約定字首

有時候分支的目的並不明確。它可能是一個新功能，一個bug修復，檔案更新，或其他任何東西。為瞭解決這個問題，通常的做法是在分支名稱上使用字首來快速解釋分支的用途。

  • feature: 將要開發的新功能。例如，feature/add-filters;
  • release：用於準備新版本。字首release/通常用於在合併來自分支master的新更新以建立釋出之前執行諸如最後一次修訂之類的任務。例如，release/v3.3.1-beta;
  • bugfix：你正在解決程式碼中的bug，並且通常與問題相關。例如，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

提交資訊

提交訊息在開發過程中非常重要。創造一個好的歷史將幫助你很多次在你的開發過程中。像分支一樣，提交也有社群建立的約定，你可以在下面瞭解到：

  • 提交訊息有三個重要部分：主題、描述和頁尾。提交的主題是必需的，它定義了提交的目的。描述（body）用於為提交的目的提供額外的上下文和解釋。最後還有頁尾，通常用於後設資料，如分配提交。雖然同時使用描述和頁尾被認為是一種良好的做法，但這不是必需的。
  • 在主題行中使用祈使語氣。舉例：

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's

“Conventional Commits規範是一個基於提交訊息的輕量級約定。它提供了一組簡單的規則來建立提交歷史。“

結構

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

提交型別

提交型別提供了一個清晰的上下文，關於在這個提交中所做的事情。下面你可以看到提交型別的列表以及何時使用它們：

  • feat：引入新功能;
  • fix：程式碼錯誤的糾正;
  • refactor：用於程式碼更改重構，保留其整體功能;
  • chore：不影響生產程式碼的更新，包括工具、配置或庫調整;
  • docs：對檔案檔案的新增或修改;
  • perf：程式碼更改增強效能;
  • style：與程式碼表示相關的調整，如格式和空白;
  • test：納入或糾正試驗相關程式碼;
  • build：影響構建系統或外部依賴項的修改;
  • ci：更改CI配置檔案和指令碼;
  • env：描述對配置項程式中的配置檔案的調整或新增，例如容器配置引數。

範圍

作用域是一種可以新增在提交型別之後的結構，以提供額外的上下文資訊：

  • 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.

Footer

提交訊息的頁尾用於提供與提交相關的附加資訊。這可以包括詳細資訊，例如誰審查或批准了更改。

示例：

Signed-off-by: John <john.doe@example.com>
Reviewed-by: Anthony <anthony@example.com>

Breaking Change

確認提交包含可能導致相容性問題或需要修改相關程式碼的重大更改。您可以在頁尾中新增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

最後

文字分享了日常開發中的git相關操作，涉及分支建立以及程式碼提交格式規範和示例，希望對你有幫助。

看完本文如果覺得有用，記得點個贊支援，收藏起來說不定哪天就用上啦～

專注前端開發，分享前端相關技術乾貨，公眾號：南城大前端（ID: nanchengfe）

相關文章