[Vibe Coder #3] AI 都把程式碼寫好了，為什麼還需要 Git？（1 分鐘回復搞砸的 App）

進行 Vibe coding 時，總會遇到這一天：你請 AI 為昨天還運作正常的 App 新增一項功能，結果 AI 到處修改，讓整個 App 都無法執行。即使你拜託它「還原成剛才的狀態」，AI 也無法精確回復。被修改的地方有 20 處，連 AI 自己也不知道問題出在哪裡。

Git 就是為了這一天而存在。很多人會問：「AI 都會記住所有程式碼了，為什麼還需要 Git？」先說結論：AI 不會記住程式碼。 對話變長就會忘記，開啟新對話又會變成一張白紙。記住程式碼過去的不是 AI，而是 Git。

Git 就是遊戲的存檔點

Git 的概念和遊戲存檔完全一樣。進入 Boss 戰前會先存檔，因為即使死亡，也能從存檔點重新開始。Git 的提交就是這個存檔。每次提交都會永久保存當下整個專案所有檔案的快照。

提交也會像存檔一樣累積。「登入功能完成」時的提交、「加入付款前」時的提交。你隨時都能回到任何時間點。AI 搞壞 App 時，這正是你需要的功能。不必從 20 個修改處找問題，只要把整個專案回到最後的存檔點即可。

只需要知道 4 個詞

Git 有幾十個指令，但 Vibe coder 只需要理解 4 個概念，連指令都不用背，反正直接用文字告訴 AI 就好。

• 儲存庫：附加在專案資料夾上的「存檔資料保管庫」。AI 程式設計工具通常會在一開始建立它。
• 提交：存檔，也就是把目前這一刻的快照記錄到保管庫。
• 推送：將存檔檔案備份到雲端。GitHub 就是備份伺服器，因此即使電腦故障，程式碼仍能保留下來。
• 回復（還原）：將整個專案回到過去的存檔點。

在 GitHub 備份時，有一點注意事項已在第 2 集說明過。如果把儲存庫設為公開（Public），機器人幾分鐘內就會掃過。除非有特殊理由，設為**私有（Private）**才是預設做法。

實戰節奏：「一個功能，一次提交」

使用 Git 可以濃縮成一個習慣：每當有一件事順利運作，就存檔一次。

• 終於能登入了 →「幫我提交目前狀態」
• 修改設計前 →「先提交，再開始修改」
• 今天工作結束 →「提交並推送到 GitHub」

不論是 Cursor 還是 Claude Code，AI 程式設計工具都能理解這些話並代你處理。不必親自輸入指令，重要的是時機。在 Boss 戰（大型修改）前不存檔，死掉時就沒有可以回去的地方。請 AI 進行大型修改前的那次提交，是最有價值的提交。

相反地，最常見的失敗是連續幾天不提交，累積一堆工作後，AI 把 App 搞壞。因為沒有可回去的存檔點，曾經正常運作的程式碼就永遠消失了。未提交的變更連 Git 也保護不了。

搞砸時：1 分鐘回復

如果 AI 搞壞了 App，請依照以下順序處理。

1. 冷靜地告訴 AI：「剛才的修改讓 App 壞掉了。請回復到最後一次提交的狀態。」
2. AI 執行回復後，提交時間點之後的所有變更都會消失，專案也會回到存檔點。
3. 確認 App 恢復運作後，將剛才失敗的修改切成更小的單位再試一次。不要一次修改 20 個地方，一次只改一件事。

這裡再次出現第 1 集的區分。回復只會還原程式碼。 DB 中累積的資料與 Git 無關，仍會原封不動地保留。即使把程式碼回到昨天的狀態，今天註冊的會員也不會消失。反過來說，誤刪的資料也無法用 Git 復原。程式碼的過去由 Git 負責，資料的過去則由 DB 備份負責。

.env檔案也一樣。第 2 集已將.gitignore加入排除清單，讓 Git 不再追蹤，因此 Git 不會保護這個檔案。重新核發金鑰後，最好另外記在密碼管理器等地方。

今天可以做的自我檢查

請這樣問 AI。

1. 「這個專案有建立 Git 儲存庫嗎？最後一次提交是什麼時候？」—如果沒有儲存庫，或最後一次提交是一週前，現在就是提交的時候。
2. 「有備份（推送）到 GitHub 嗎？儲存庫是公開還是私有？」—如果沒有備份，就請 AI 建立；如果目前公開，請考慮切換為私有。
3. 「未提交的變更累積了多少？」—如果目前運作正常，就立即請 AI 提交。

總結

• AI 無法記住程式碼的過去，記憶是 Git 的工作。
• 提交是存檔，推送是雲端備份（GitHub），回復是返回存檔點。
• 節奏只有一個：每當程式順利運作，以及大型修改前，都說「幫我提交」。
• 回復只會還原程式碼。DB 資料和.env屬於 Git 之外的世界。
• 除非有特殊理由，儲存庫預設應設為私有。

下一集是部署。我們會說明為什麼在自己電腦上完美運作的 App，放到網際網路上卻無法運作，以及 localhost、伺服器、網域和環境變數各自代表什麼。