WALUDO 工具箱
DOCS.01 WALUDO DOCS

Git 備忘錄

Git 常用指令速查手冊，涵蓋設定、分支、提交、合併、復原、遠端儲存庫與約定式提交規範，並提供可編輯、可複製的日常開發與故障排除範例。

快速導覽

常用指令

以下大部分指令整理自 it-tools.tech，並根據實際開發經驗補充了其他用法。

程式碼區塊中的藍色文字可以編輯，方便快速修改與複製。

設定

設定全域使用者名稱與電子郵件：

bash 
git config --global user.name "WaLudo"
git config --global user.email "waludo@gmail.com"

開始新專案

初始化新的 Git 儲存庫：

bash 
git init

複製現有的 Git 儲存庫：

bash 
git clone https://github.com/WaLudo/waludo-tools.git

提交

提交所有已追蹤的變更：

bash 
git commit -am "feat: add two cups of coffee"

提交所有變更：

bash 
git add .
git commit -m "feat: add five cups of coffee"

將新修改追加到上一次提交：

bash 
git commit --amend --no-edit

我弄錯了

修改最近一次提交的訊息：

bash 
git commit --amend

復原最近一次提交，但保留變更：

bash 
git reset HEAD~1

復原最近 N 次提交，但保留變更：

bash 
git reset HEAD~N

復原最近一次提交並捨棄所有變更：

bash 
git reset HEAD~1 --hard

將本地分支重設為遠端狀態：

bash 
git fetch origin
bash 
git reset --hard origin/branch-name

其他

將本地 master 分支重新命名為 main：

bash 
git branch -m master main

提交規範

請參考 約定式提交 v1.0.0 規範。

驗證提交是否符合規範

git commit -m "feat(scope): description"

Type 類型速查

類型說明
fix修正錯誤
feat新增功能
build修改建置系統（依賴套件、外部介面、Node 版本等）
chore非業務性程式碼修改（建置流程、工具設定等）
ci修改持續整合流程（CI/CD 設定）
docs修改文件（README、API 文件等）
style修改程式碼樣式（縮排、空白、空行等，不影響邏輯）
refactor重構程式碼（修改結構或命名，不改變功能）
perf效能最佳化
test修改測試案例

Scope 範圍

可以在提交類型後以括號標示範圍，提供額外的上下文：

feat(parser): adds ability to parse arrays

破壞性變更

! 代表破壞性變更，可以附加在任何類型上：

feat(api)!: send an email to the customer when a product is shipped

也可以在腳註中加入 BREAKING CHANGE，達到相同效果。

多行正文與腳註

多行正文與腳註的提交範例：

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

完整規範

本文中的關鍵詞 “必須”、“禁止（MUST NOT）”、“必要（REQUIRED）”、“應當（SHALL）”、“不應當（SHALL NOT）”、“應該（SHOULD）”、“不應該（SHOULD NOT）”、“推薦（RECOMMENDED）”、“可以（MAY）” 與 “可選（OPTIONAL）” 的解釋，請參考 RFC 2119。

  • 每個提交必須以類型欄位開頭，後面依序可以有可選的範圍欄位、可選的 !，以及必要的英文半形冒號與空格
  • 實作新功能時，必須使用 feat 類型
  • 修正錯誤時，必須使用 fix 類型
  • 範圍欄位可以接在類型欄位後，必須是描述程式碼某部分的名詞，並以括號包圍，例如 fix(parser):
  • 描述欄位必須緊接在 <類型>(範圍) 前綴的冒號與空格之後
  • 簡短描述之後可以加入較長的提交正文，正文必須從描述欄位結束後的一個空行開始
  • 正文結束的一個空行之後可以加入一行或多行腳註，每行腳註必須包含一個 token，並以 :<space> 或 <space># 分隔
  • 腳註的 token 必須使用 - 代替空白（例如 Acked-by）；例外是 BREAKING CHANGE 可以作為 token
  • 破壞性變更必須在提交訊息中標示：在 <類型>(範圍) 前綴使用 !，或加入 BREAKING CHANGE: <描述> 腳註
  • 如果使用 !，腳註中可以省略 BREAKING CHANGE:，描述應該用來說明破壞性變更
  • 除了 feat 與 fix 外，可以使用其他類型，例如 docs: updated ref docs.
  • 實作約定式提交規範的工具必須不區分大小寫地解析各個資訊單元，唯一例外是 BREAKING CHANGE 必須使用大寫
  • BREAKING-CHANGE 作為腳註 token 時，必須視為 BREAKING CHANGE 的同義詞