快速導覽
常用指令
以下大部分指令整理自 it-tools.tech，並根據實際開發經驗補充了其他用法。
程式碼區塊中的藍色文字可以編輯，方便快速修改與複製。
設定
設定全域使用者名稱與電子郵件：
bash
git config --global user.name "WaLudo"
git config --global user.email "[email protected]"開始新專案
初始化新的 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的同義詞