今天我們不講程式、不講架構，來聊一個幾乎所有開發者都在用的工具：Git。
但這次不講指令大全，而是聊聊「為什麼你的 Git 流程讓同事抓狂」，
以及怎麼讓自己的 commit log 更有價值、怎麼救回壞掉的分支、
還有那句老話：「Git 永遠知道你幹了什麼」。

1. Commit 不是儲存點，是故事節點

很多人把 Git 當成「儲存狀態」的工具，像存遊戲進度一樣，
寫到一半就 git add . && git commit -m "WIP"。

這沒錯，但若整份專案都是「WIP、fix、try again、test123」，
日後任何人（包含你自己）都無法理解當時的改動。

改善方式：

• 每次 Commit 應代表一個邏輯單元（Logical Unit of Change）

  • 例如：「新增 KD 計算邏輯」、「修正 MACD NullReference 問題」

• 訊息應有動詞開頭

  • 「Add KD calculation service」
  • 「Fix incorrect MACD histogram formula」

• 避免一次 Commit 太多東西

  • 若你在同一個 commit 同時改 UI + 改演算法，那就太難回溯了。

2. Commit Message 是給未來的你看的

永遠假設：

你半年後完全不記得自己改了什麼。

這樣你就會開始寫出比較像樣的 commit 訊息。

好訊息範例：

Fix: null reference when MACDHist is not initialized
Refactor: move indicator calculation to IndicatorService
Add: error logging for API timeout with parameter details

壞訊息範例：

update
debug again
temp fix
final version

當 Log 變成這樣，你的 Git 就只剩下「歷史垃圾堆」。

3. Branch 命名是溝通的一部分

分支名稱其實是另一種「文件」。
看到分支名就應該知道大致在做什麼。

建議格式：

feature/add-lite-db-repository
bugfix/fix-null-exception-on-api
refactor/rename-service-classes
hotfix/update-finmind-token-env

命名時盡量簡短，但要清楚職責與範疇。

4. Rebase 不可怕，亂用才可怕

很多人聽到 git rebase 就怕，覺得會炸掉歷史。
但其實 rebase 是為了讓歷史乾淨。

在團隊開發中，
當你從 main 開了一條 feature/xxx 分支，開發完要合併前：
可以先：

git fetch origin
git rebase origin/main

這會把你的分支「平順」地接到最新 main 上，
比起 merge 多一層「merge commit」更乾淨。

規則是：公開分支不要 rebase，私人分支可以。

5. 永遠記得：Git 不會忘記

你可以強制 reset、force push、刪除 branch，
但 Git 其實都留有痕跡（reflog、object）。

當你覺得「完了我剛剛整個刪掉了」時，
先冷靜，執行：

git reflog

Git 會列出所有 HEAD 的變化紀錄。
找到那個 commit id：

git checkout <commit_id>

你就能回到當時的狀態。

6. Try-Catch 的精神，也該用在 Git

這裡連結前一篇（Day 27）：
我們說過 try-catch 要記錄參數，讓未來能還原現場。

Git 也是同理。
每一次 commit、branch、merge、tag，
其實都是你在為未來「還原現場」做準備。

當你留下好的 commit 訊息、清楚的 branch 命名、
規律的推送與備份，
未來出現問題時就能「直接 git log / blame / diff」重現當時狀態。

7. 常見「讓同事痛苦」的 Git 習慣

8. 小結

Git 不是版本控制而已，它是開發溝通的語言。

寫出好的 commit log，不只是幫助別人，
也是幫助未來的自己理解「當時的思考」。

一個乾淨的專案歷史，
能讓你在任何時刻都能快速回到問題現場，
這就像在系統中留下一份有價值的 Log。