整合 Git 追蹤進度

6.1　先配 Git：你的「時光機」與安全網

Claude 能直接改你電腦裡的檔案——這正是它好用的地方，但也代表萬一它改錯了，你的原稿可能被蓋掉。解法很簡單：先幫專案配一個叫 Git 的工具。每次重要節點做一次 commit，就等於拍下一張「當下的快照」，之後可以比較或回到那一張。把它想成專案的時光機：走錯路時，先看清楚目前有哪些改動，再決定怎麼倒帶。

你可能會想起第 4 章提過的 /rewind——那個能讓你反悔剛剛幾步的 checkpoint 機制。這兩者常被搞混，但差別是關鍵：checkpoint 比較像隨手可撕的便條紙，只在「這次對話」裡有效，換一輪新的對話它就不算數；Git 這台時光機才是正式歸檔的資料夾——不管隔了多久、換了幾輪對話，只要你當初有 commit，那個版本就一直在，隨時能翻出來。

配 Git 前先確認這個資料夾是不是已受 Git 管理。只有尚未受管理的練習資料夾才需要初始化；從 GitHub clone 下來的專案，或 Git 專案裡的子資料夾，通常不用再做一次。確認後有兩條路：完全不想碰指令的人，直接請 Claude 幫忙；想自己動手的人，再在專案資料夾裡執行 git init。

1. 1
   ✋動手做

   打開你要工作的專案資料夾

   先用終端機進到你的專案資料夾（第 1 章教過的 cd）。接下來的動作都要在這個資料夾裡做，Git 才會認得是哪個專案。

2. 2
   ✋動手做

   先確認，再決定要不要設成 Git 專案

   先在專案資料夾輸入 git status。如果看到分支、檔案狀態或「working tree clean」，代表這個專案已經是 Git 專案，不要再執行 git init；直接跳到下一節即可。只有看到「not a git repository」時，才選下面其中一種方式初始化。第一次練習請在你自己建立、沒有重要檔案的資料夾進行。

   Windows Mac Linux
3. 3

   確認 Git 認得這個專案了

   設定完，請 Claude 或自己打 git status，看到它開始「報告狀態」就成功了。

   ✅ 預期會看到

   # 大致會看到這類訊息（實際文字依情況略有不同）
   On branch main
   No commits yet
   nothing to commit (create/copy files and use "git add" to track)

   複製

6.2　讓 Claude 幫你 commit（不用背 Git 指令）

配好 Git 之後，最常做的事就是「存檔」——也就是 commit。好消息是你完全不用記指令，直接用講的就好。每做完一段告一段落的工作，就請 Claude 幫你存一次。

一次 commit 會把你這次改了哪些東西打包記下來，並附上一句說明（之後你回頭找版本時，靠這句話就認得出是哪一次改的）。請它做的時候，它會自動：整理這次的改動 → 幫你寫好清楚的說明 → 完成存檔，一條龍。

💡 建議執行：做完一段就請它存一次

幫我把這次的修改 commit，並寫一個清楚的說明。

（習慣英文的人也可以直接打：claude "commit my changes with a descriptive message"，效果一樣。）

{
  "attribution": { "commit": "", "pr": "" }
}

6.3　開分支、開 Pull Request

如果你想試一個新點子，又怕改壞現在好好的版本，分支就是為這個而生的。它像幫你開一個「平行時空」：你在裡面盡情實驗、做新功能，完全不影響原本的主線。試成功了就合併回來，試壞了就丟掉那個時空，主線毫髮無傷。

做完一個分支的東西，通常會開一個 Pull Request（簡稱 PR），意思是「我這邊改好了，請看一下、把它合併回主線」。團隊一起做事時這是最常見的流程；就算只有你自己一個人，用 PR 也能讓每次改動留下清楚的紀錄。這些你都不用手動操作，講給 Claude 聽就好。

💡 建議執行：用講的請它開分支、開 PR

幫我開一個新分支叫 feature/login，把這個登入功能做在這個分支上。

做完幫我開一個 Pull Request。

它會幫你建好分支、把改動推上去、開好 PR，整個流程一氣呵成。

想讓 PR 說明更完整？拆成幾句話跟它說

一句「幫我開一個 PR」通常就夠用，Claude 會自己去看這個分支跟主線差在哪裡，生出一份說明。但如果這次改動比較大、想要說明寫得更仔細，拆成幾個步驟講效果會更好——因為每一句都多給它一點「這次到底改了什麼、為什麼改」的線索：

# 第一步：先請它摘要這次改了什麼
幫我摘要這次的修改內容。

# 確認摘要沒問題，再請它開 PR
幫我開一個 Pull Request。

# 想要說明更完整，再追加這句
PR 說明可以再寫詳細一點嗎？把改動的原因也帶進去。

訣竅是先讓它看過完整的改動，再動筆寫說明。如果劈頭就要它「寫 PR 說明」，手上卻只有零星幾句對話可以參考，寫出來的說明常常很空泛（像「一些小修正」這種沒營養的句子）；先摘要、再開 PR、有需要再加碼補細節，是比較穩的順序。

💡 進階：推上去之前，先讓它自己審一遍

/code-review

這個指令會請 Claude 切換成「審查者」角度，重新看一遍目前分支上還沒併回主線的改動，抓明顯的 bug 或寫法疏漏。先看它回報的問題與建議，再決定是否修正；不要因為它說「完成」就略過 diff 與必要檢查。以後如果你的專案想要「每個 PR 都自動被審一遍」而不用自己動手打指令，第 11 章會教你怎麼把這個能力接進 GitHub，變成全隊都受惠的自動化。

6.4　處理合併衝突

有時候兩個人、或兩個分支，剛好改到同一行程式，Git 就不知道該聽誰的——這就叫 merge conflict（合併衝突）。第一次遇到別慌，這在團隊協作裡很常見，而且不難解。

第一次親眼看到，它長得像這樣——Git 把兩邊的版本都攤開來，用符號夾在中間，等你（或 Claude）決定要留哪個：

<<<<<<< HEAD
這是你這邊的版本
=======
這是另一邊（分支或別人）的版本
>>>>>>> feature/login

<<<<<<< HEAD 到 ======= 之間是你這邊的版本，======= 到 >>>>>>> 之間是對方的版本——這些符號不是錯誤訊息，是 Git 老實告訴你「這裡我沒辦法自己決定，兩份都先留著」。

你不需要自己一行一行去比對，直接請 Claude 幫你處理就好。它會把衝突的地方一個一個攤開、判斷該保留哪邊（或兩邊都留），逐一幫你收拾乾淨。

💡 建議執行：交給它逐一處理

幫我解決這些合併衝突。

6.5　worktree：同時平行做好幾件事

6.3 的「分支」讓你開出平行時空，但一次只能站在一個時空裡——切過去做 A，就離開了 B。如果你想真的同時做好幾件事（一邊讓 Claude 開發新功能、另一邊同時修一個 bug），這就輪到 worktree 出場了。

一句話說：worktree 讓你在同一個專案底下，開出好幾個各自獨立的工作資料夾，每個資料夾待在不同的分支上、互不干擾。配合多個 Claude（多代理人）一起跑，就能讓它們平行改不同分支而不會打架——A 在它的資料夾蓋房子，B 在它的資料夾修水管，兩邊的檔案完全不會互相覆蓋。

你幾乎不用記指令：在 Claude 對話中直接說「在 worktree 裡工作」，它就會自己幫你開好一個獨立工作區。這是進階用法，新手現在看過、知道有這條路就好，等你開始想「一次推進好幾件事」時再回來用。

# 最省事：在對話中直接請 Claude 幫你開
幫我在一個 worktree 裡工作。

想更精確一點，也可以直接在啟動指令上加 --worktree（簡寫 -w）帶一個名字，Claude 會自動幫你開好一塊獨立工作目錄、切到一個新分支，這個對話之後所有的讀檔、改檔都只發生在那塊目錄裡，完全不會碰到你原本工作中的檔案：

# 開一塊叫 feature-x 的獨立工作區，直接進去工作
claude --worktree feature-x

# 也可以直接指向一個既有的 PR 編號，開一塊專屬工作區研究它
claude --worktree "#1234"

第二種寫法很適合接續 6.3 的 PR 場景——想仔細看一個同事開的 PR，又不想動到手上正在做的東西，開一塊專屬工作區看就對了。這裡只是先破題，完整的 worktree 玩法（怎麼指定用哪個分支當起點、怎麼讓多個子代理各拿一塊互不干擾），第 18 章「平行與 Worktree」有一整章專門教。

不透過 Claude、想自己手動管理 worktree 也完全可以，就是幾個標準 Git 指令：

# 開一個新工作區，並在上面建一個新分支 feature-a
git worktree add ../project-feature-a -b feature-a

# 看看目前開了哪些工作區
git worktree list

# 用完了，把這個工作區收掉
git worktree remove ../project-feature-a