前言：那次 AI 把我做了三天的東西毀掉

我永遠記得那天。

我用 Claude Code 花了三天做了一個部門用的加班費計算工具。功能都做好了，也測試過了。最後我想加一個「匯出 PDF」的功能，於是跟 Claude Code 說：「幫我加 PDF 匯出功能。」

它開始動工。改了好幾個檔案，加了新的程式碼⋯⋯然後東西壞了。不只是 PDF 功能沒做好，連原本正常的計算功能都壞了。

我慌了：「幫我改回來。」它改了，但改得更奇怪了。原本的計算邏輯已經面目全非。

那一刻我才意識到：我沒有存檔。三天的心血，沒有任何一個可以回去的版本。

後來我用了整整兩天重做。從那天起，我開始認真學 Git。

現在回頭看，那次災難其實只需要一個指令就能解決：git checkout .——兩秒鐘回到上一個正常的版本。

這篇文章，就是要教你這件事。

Git 是什麼？用「遊戲存檔」來理解

如果你只需要記住一個概念，就是這個：

Git 就是你程式的存檔系統。

想像你在玩一款冒險遊戲：

  • 手動存檔（commit）：在任何時刻按下「存檔」，記錄當前的狀態
  • 讀取存檔（checkout）：打輸了，可以回到上一個存檔點重來
  • 多條路線（branch）：想試試不同的打法？開一條新路線，失敗了不影響主線
  • 存檔紀錄（log）：回頭查看所有存檔的時間和說明

在 AI 開發裡，Git 的價值更大。因為你不是自己寫程式——你是讓 AI 幫你寫。你看不到它改了什麼，也無法保證它不會動到不該動的東西。Git 就是你的安全網：

沒有 Git 有 Git
AI 改壞東西，回不去 一個指令回到上個版本
不敢讓 AI 大膽嘗試 先存檔再試，壞了就回溯
不知道 AI 改了什麼 一個指令看所有變更
做了三天全部丟掉 每個階段都有存檔

安裝與設定：一次搞定

確認 Git 是否已安裝

打開終端機，輸入：

git --version

如果看到版本號（像 git version 2.45.0），代表已經裝好了。

如果沒有，到 git-scm.com 下載安裝。Mac 使用者通常已經內建。

第一次使用的設定

只需要做一次，告訴 Git 你是誰：

git config --global user.name "你的名字"
git config --global user.email "你的email"

這不會註冊任何帳號，只是在存檔紀錄裡標記作者。

六個核心指令：這些就夠了

Git 有幾十個指令，但日常開發真正會用到的就這六個。我按照使用頻率排給你：

指令 1：git init — 開啟存檔系統

在你的專案資料夾裡，只需要執行一次：

cd ~/Desktop/my-tool
git init

這會在資料夾裡建立一個隱藏的 .git 資料夾，從此這個資料夾就有版本控制了。

什麼時候用：新專案的第一件事。在打開 Claude Code 之前就先做。

指令 2：git add + git commit — 存檔

這是你最常用的組合，把當前的變更存成一個版本：

git add .
git commit -m "feat: 完成基本計算功能"
  • git add .：把所有變更標記為「準備存檔」
  • git commit -m "說明"：正式存檔，附上一句說明

存檔說明（commit message）建議用這個格式——前面加一個類型前綴：

feat: 新增了某個功能
fix: 修正了某個問題
style: 調整外觀，不影響功能
refactor: 重構程式碼，行為不變但結構更好
docs: 更新文件

為什麼要這樣寫？因為三個月後你回來看紀錄，feat: 新增 PDF 匯出功能 一眼就知道這次做了什麼；update 三個字什麼都沒告訴你。

什麼時候用：每完成一個功能就存一次。寧可多存，不要少存。

指令 3：git status / git diff — 看看現在的狀態

git status      # 看哪些檔案被改了
git diff        # 看具體改了什麼內容
什麼時候用：AI 做完一輪修改後，先看看它改了什麼，再決定要不要存檔。這一步很重要——AI 有時候會「順手」改了你沒要求它改的東西。

指令 4：git log --oneline — 查看版本紀錄

git log --oneline

會顯示像這樣的清單：

a3d8f2e feat: 加入 PDF 匯出功能
7b1c9a4 feat: 完成報表顯示功能
e5f2d1b feat: 完成基本計算功能
3c8a7f0 feat: 建立專案基礎架構

每一行就是一個版本，前面的代碼是版本 ID。因為有清楚的前綴，不用點進去就知道每次做了什麼。

什麼時候用：想知道自己做到哪裡了，或想找到某個版本的 ID。

指令 5：git checkout . — 後悔藥

git checkout .

這就是後悔藥。 它會把所有還沒存檔的變更全部撤銷，回到上一次 commit 的狀態。

什麼時候用：AI 把東西改壞了，你想回到上一次「一切正常」的狀態。

指令 6：git checkout -b — 開分支

git checkout -b feature/export-pdf    # 建立新分支並切換過去
git checkout main                     # 切回主線

分支的概念很簡單：你目前的主線（main）是穩定、可用的版本。當你要做一個不確定結果的改動時，開一條分支出去做。成功就合併回來，失敗就刪掉，主線完全不受影響。

什麼時候用：要做比較大的改動、嘗試新方案、或任何你不確定結果好不好的事情。

六個指令速查卡

git init                                    # 開啟版本控制（只做一次）
git add . && git commit -m "feat: 說明"     # 存檔
git status / git diff                       # 看 AI 改了什麼
git log --oneline                           # 查看版本紀錄
git checkout .                              # 後悔藥（撤銷未存檔的變更）
git checkout -b feature/功能名稱             # 開分支做新功能

實戰流程：用 Claude Code 開發時的正確節奏

知道指令是一回事，知道什麼時候用才是關鍵。

讓我用「開發一個會議記錄整理工具」當例子，帶你跑一遍完整的開發節奏。

第〇步：建立專案 + 初始化 Git + 設定 .gitignore

mkdir ~/Desktop/meeting-notes-tool
cd ~/Desktop/meeting-notes-tool
git init

然後建立 .gitignore 檔案。這個檔案告訴 Git 哪些東西不要存——像是密碼、API 金鑰、系統暫存檔，這些不該被記錄下來：

claude

進入 Claude Code 後：

幫我建立一個 .gitignore 檔案，
忽略 .env、node_modules、.DS_Store 和常見的暫存檔案。

然後做第一次 commit：

git add . && git commit -m "feat: 初始化專案"

這是你的起點。從此之後的每一步，都可以回到這裡。

第一步：基礎架構 → 確認 → 存檔

幫我建立一個會議記錄整理工具的網頁版。
先做基礎架構：一個輸入框讓人貼上會議記錄，
一個輸出區域顯示整理後的結果。
單一 HTML 檔案就好。

Claude Code 建好 index.html 後，打開瀏覽器看一下——版面沒問題？存檔：

git add . && git commit -m "feat: 建立基礎架構，輸入框和輸出區域"

第二步：加入功能 → 確認 → 存檔

加入會議記錄自動整理功能：
把貼上的文字整理成「會議日期 / 出席者 / 討論事項 / 決議 / 待辦」的格式。

看效果，測試一下——沒問題？存檔：

git add . && git commit -m "feat: 完成會議記錄自動整理功能"

第三步：開分支做新功能

現在你想加「匯出 Word 檔」的功能。這個功能可能影響比較多東西，穩妥的做法是開一條分支來做：

git checkout -b feature/export-word

現在你在 feature/export-word 分支上了。接下來所有改動都在這裡，不影響主線。

加入「匯出為 Word 檔」的功能，
一個按鈕，點下去把整理好的內容下載成 .docx 檔案。

做完之後，先審查一下 AI 的改動：

git diff

確認它沒有動到不該動的東西。沒問題就存檔：

git add . && git commit -m "feat: 加入 Word 匯出功能"

第四步：審查後合併，或者放棄

功能做好了，在合併回主線之前，讓 Claude Code 幫你做一次快速審查：

在合併到 main 之前，幫我檢查一下 feature/export-word 分支的改動：
- 有沒有影響到原本的整理功能？
- 有沒有明顯的 bug？

Claude Code 會比對兩個分支的差異，告訴你它看到什麼。

審查通過 → 合併回主線：

git checkout main
git merge feature/export-word
git branch -d feature/export-word

如果這個功能搞砸了 → 刪掉分支，主線毫髮無傷：

git checkout main
git branch -D feature/export-word

完整流程圖

  開始新功能
     ↓
  git checkout -b feature/功能名稱（開分支）
     ↓
  跟 Claude Code 說需求
     ↓
  AI 做完 → git diff（審查改動）→ 自己測試
     ↓
  ┌─ 沒問題 → git commit → 審查 → merge 回 main
  │
  └─ 有問題 → git checkout .（回到上個版本）
               ↓
             換個方式重新跟 AI 說

這個循環就是 AI 開發的核心節奏。 每個功能一條分支，做完審查再合併。聽起來多了幾步，但這幾步正是讓你不會在某天突然發現「東西壞了回不去」的關鍵。

讓 Claude Code 幫你管理 Git

Claude Code 本身就會 Git。你不需要離開對話去終端機打指令，可以直接口語化地跟它說：

你說 Claude Code 會做什麼
「幫我 commit，message 幫我寫」 分析改動內容，寫出帶前綴的 commit message
「剛才的改動回復掉」 執行 git checkout . 撤銷變更
「開一個 feature branch 來做匯出功能」 建立 feature/export 分支
「做完了，合併回 main」 切回 main、merge、刪除分支
「讓我看看目前改了什麼」 執行 git diff 並用白話解釋改動
「合併前幫我審查一下」 比對分支差異，逐項檢查問題
「建一個 PR 到 main」 推到 GitHub、撰寫 PR 說明、建立 PR

這帶出一個重要的觀念：你不需要記住所有 Git 指令，但你需要知道什麼時候該做什麼事。

知道「做新功能前要開分支」比知道 git checkout -b 的語法更重要。因為語法可以讓 AI 幫你打，但時機判斷只有你自己能做。

AI 開發的 Git 紀律：八個原則

以下是我踩了無數坑之後歸納出來的原則。每一條都有對應的慘痛教訓。

1. 動手前先 git init

不管要做什麼，第一件事就是初始化 Git。就像開車先繫安全帶——你可能不會出事，但萬一出事，它會救你一命。

2. 一次 commit 只做一件事

這是版本控制最重要的原則，沒有之一。

✅ 正確的做法：
commit 1: feat: 完成資料輸入功能
commit 2: fix: 修正計算邏輯的四捨五入問題
commit 3: style: 調整按鈕配色

❌ 常見的錯誤：
commit 1: 改了一堆東西

為什麼？因為如果 commit 3 出了問題，你只需要撤銷 commit 3，前兩個完好無損。如果全部混在一起，撤銷就變成「全部撤銷或全部保留」的兩難。

如果你不小心一次做了好幾件事，可以跟 Claude Code 說：

我剛才同時做了三件事，幫我分成三個獨立的 commit。

它會用 git add 精確挑選每個 commit 該包含的檔案，而不是全部打包。

3. 新功能開分支，不在 main 上冒險

main 分支永遠保持在「穩定可用」的狀態。所有新功能都在自己的分支上開發：

main（穩定）──────────────────────────────→
     ↘                         ↗
      feature/export-pdf ──────（成功，合併回來）
     ↘
      feature/dark-mode ──────✕（失敗，刪掉，main 不受影響）

什麼時候一定要開分支？

  • 加入可能影響多個檔案的功能
  • 嘗試不同的技術方案或設計
  • 任何你不確定結果好不好的改動
  • 讓 AI 做大規模重構

4. AI 改完先 git diff 再 commit

不要盲目存檔。AI 改完後，先看一下它到底改了什麼。

這一步的重要性怎麼強調都不為過。AI 有時候會「順手」改了你沒要求它改的東西——改了一個不相關的函式、刪了一段它覺得「多餘」的程式碼、或是調整了你刻意設定的格式。

先看過再存，才能確保你存進去的都是你想要的。

5. 合併前做審查

在把分支合併回 main 之前，花一分鐘讓 Claude Code 幫你看一遍：

幫我比較 feature/export-pdf 和 main 的差異，
檢查有沒有影響到現有功能或明顯的 bug。

這就是軟體團隊裡的「Code Review」。在團隊裡通常是讓同事幫你看，一個人開發時就讓 AI 幫你看。目的是一樣的：多一雙眼睛，少一個 bug。

6. Commit message 認真寫

好的 commit message 是三個月後的你會感謝自己的投資：

# ✅ 看了就知道做了什麼
git commit -m "feat: 加入加班費計算，支援平日/假日/國定假日三種費率"
git commit -m "fix: 修正匯出 CSV 時中文變亂碼的問題"

# ❌ 跟沒寫一樣
git commit -m "update"
git commit -m "fix bug"

如果你懶得想，交給 Claude Code。跟它說「幫我 commit」，它會分析改動內容，自動寫出清楚的 message。

7. 推上 GitHub 當備份

Git 的存檔預設存在你的電腦上。如果電腦壞了、被偷了、或不小心刪了資料夾⋯⋯存檔也沒了。

推上 GitHub 就是雲端備份。直接跟 Claude Code 說：

幫我在 GitHub 建立一個 private repo，把這個專案推上去。

之後每次開發完，都可以推上去：

幫我把最新的改動推到 GitHub。

如果你的專案有推到 GitHub，合併分支時還可以用 Pull Request（PR）——它不只是合併程式碼，更是一份改動紀錄，記錄你為什麼做這個改動、改了什麼、怎麼測試的。三個月後回頭看，每一次功能新增都有完整脈絡。

功能做完了，幫我建一個 PR 到 main，說明幫我寫好。

8. Git 紀錄就是專案記憶

你昨天用 Claude Code 做了一半，今天開新 session 繼續。Claude Code 不記得昨天的對話了，但 Git 紀錄還在：

這個專案是一個會議記錄整理工具，
看一下 git log，了解目前做到哪裡了，然後繼續開發。

Claude Code 會讀 Git 紀錄，快速掌握專案脈絡。所以前面說的「commit message 認真寫」不只是為了你自己看——也是為了讓 AI 能快速理解你的專案。紀錄寫得好，AI 接手得就越順。

真實情境劇場：四個「Git 救了我」的故事

情境一：AI 改壞了不該動的東西

做薪資計算工具，AI 在加「獎金計算」功能時，不小心改了原本的「基本薪資計算」公式。

沒有 Git：花兩小時人工對照，試圖手動改回去，越改越亂。

有 Git：

git diff                    # 一看就知道它動了哪裡
git checkout -- salary.js   # 只回復這一個檔案，其他改動保留

30 秒搞定。git checkout -- 檔案名 可以只撤銷特定檔案，不用全部砍掉重練。

情境二：想比較兩種設計方案

做 HR 儀表板工具，想試「側邊欄導航」和「頂部導航」兩種介面，不確定哪個好看。

# 在分支 A 做側邊欄
git checkout -b feature/sidebar-nav
# ...Claude Code 做側邊欄版本...
git add . && git commit -m "feat: 側邊欄導航版本"

# 回主線，在分支 B 做頂部導航
git checkout main
git checkout -b feature/topbar-nav
# ...Claude Code 做頂部導航版本...
git add . && git commit -m "feat: 頂部導航版本"

# 兩個版本都在，隨時切換比較
git checkout feature/sidebar-nav   # 開瀏覽器看側邊欄版
git checkout feature/topbar-nav    # 開瀏覽器看頂部導航版

# 決定了？合併喜歡的那個
git checkout main
git merge feature/topbar-nav

兩種方案同時存在，切換比較，選好再合併。不用做兩次、不用複製兩份資料夾。

情境三：同事急著用，但你的功能還沒做完

你的工具做到一半，有些功能還不穩定。但同事今天就要用。

git log --oneline
# a3d8f2e feat: 嘗試加入 PDF 匯出（有 bug）
# 7b1c9a4 feat: 完成報表功能
# e5f2d1b feat: 完成計算功能     ← 這個版本一切正常
# 3c8a7f0 feat: 初始化專案

# 從穩定的版本建立一條分支，把檔案給同事
git checkout -b release/stable e5f2d1b

同事拿到穩定版，你繼續在 main 上開發。兩邊互不干擾。

情境四：用 Git 紀錄讓 AI 快速接手

昨天用 Claude Code 做了一半，今天開新 session，AI 什麼都不記得了。

但你的 Git 紀錄寫得很清楚：

a3d8f2e feat: 加入匯出功能（支援 CSV 和 PDF）
7b1c9a4 fix: 修正日期格式在 Safari 上的相容性問題
e5f2d1b feat: 完成會議記錄整理邏輯
3c8a7f0 feat: 建立基礎架構，輸入框和輸出區域

跟 Claude Code 說：

看一下 git log 和程式碼，了解這個專案的脈絡，然後繼續開發。

因為每個 commit 都有清楚的前綴和說明，Claude Code 幾秒鐘就能掌握：這是一個什麼工具、做到哪裡了、用了什麼技術。

你寫給 Git 的紀錄，同時也是在寫給未來的 AI 讀的文件。

完整工作流全景圖

  開新專案
     ↓
  git init + .gitignore + 第一次 commit
     ↓
  ┌────────── main（永遠保持穩定可用）──────────────────┐
  │                                                    │
  │  ① feat: 初始化  →  ② feat: 基礎架構               │
  │                              ↓                     │
  │                    開分支做新功能                    │
  │                    git checkout -b feature/xxx      │
  │                              ↓                     │
  │  ┌─── feature/xxx ──────────────────────┐          │
  │  │                                      │          │
  │  │  開發 → git diff 審查 → commit       │          │
  │  │  開發 → git diff 審查 → commit       │          │
  │  │                ↓                     │          │
  │  │  讓 AI 審查整個分支的改動              │          │
  │  │                ↓                     │          │
  │  │  ┌─ 通過 → merge 回 main             │          │
  │  │  └─ 不通過 → 修正後重新審查           │          │
  │  └──────────────────────────────────────┘          │
  │                                                    │
  │  ② → ③ feat: 新功能  →  ④ fix: 修正  →  ⑤ feat... │
  │                                                    │
  └────────────────────────────────────────────────────┘
                          ↓
                   推到 GitHub 備份
                   （可用 PR 記錄每次合併的脈絡）

常見問題 FAQ

「我不小心 commit 了不該存的東西」

跟 Claude Code 說：

我剛才那個 commit 要撤銷，
幫我回到 commit 之前的狀態，但保留檔案的變更。

它會執行 git reset --soft HEAD~1，把 commit 撤銷，但改動還在，不會消失。你可以調整後重新 commit。

「merge 的時候出現衝突」

衝突（conflict）代表兩邊改了同一個地方，Git 不知道該留哪個。直接跟 Claude Code 說：

merge 出現衝突了，幫我看一下，保留比較合理的版本。

它會分析衝突的內容，問你想保留哪邊，然後幫你處理。

「我的專案很小，真的需要開分支嗎？」

如果改動很小（改個文字、調個顏色），直接在 main 上做沒問題。但只要你心裡有一絲「這個改動可能會搞砸」的念頭，就開分支。開分支的成本是兩秒鐘打一行指令，搞砸之後重做的成本可能是兩天。

「我真的需要推上 GitHub 嗎？」

自己練習的小東西不推也行。但如果是有用的工具或你花了超過一天做的——推上去吧。多一層保險永遠不嫌多。而且 GitHub 上的 PR 紀錄，是你做過所有改動的最好文件。

結語：Git 不是額外的工作，是 AI 開發的基礎設施

很多人覺得 Git 是「額外的步驟」，要多打幾行指令，好麻煩。

但你換個角度想：用 AI 寫程式，你交出了對程式碼的直接控制權。你看不到 AI 改了什麼、不確定它有沒有動到不該動的地方、也無法保證每次改動都是進步而不是倒退。

在這個情況下，Git 不是額外的工作，它是讓你敢放手讓 AI 做事的底氣。

有了 Git，你可以大膽地說：「試試看用完全不同的方式重做。」因為你知道，不管結果如何，穩定的版本永遠在那裡等你。

有了分支，你可以同時探索三種設計方案，不用擔心搞亂主線。

有了清楚的 commit 紀錄，你的 AI 即使換了一個 session，也能在十秒鐘內接手你的專案。

有了 GitHub 和 PR，你的每一次改動都有完整的脈絡紀錄，三個月後回來看，依然清清楚楚。

這些不是高深的技術。這是讓你在 AI 時代安心創作的基礎設施。

六個指令、一個習慣，就能讓你從「AI 改壞就完蛋」變成「大膽嘗試，穩穩前進」。

歡迎來到工人智慧。