用 Claude Code 做 Vibe Coding 時，你一定遇過這種情況：好不容易把功能調到滿意了，結果下一輪對話就不小心改壞了什麼，卻怎麼也回不到剛才正常的狀態。
這時候你可能會想，如果有一個「時光機」，能讓我隨時回到任何一個正常運作的版本就好了。
這個時光機，就是 Git。
Git 是目前最主流的版本控制工具。簡單來說，它會幫你記錄專案裡每一次的改動，讓你可以隨時回頭查看、比較、甚至回到之前的任何一個狀態。
對 Vibe Coder 來說，學 Git 最大的好處是：你可以放心地讓 Claude Code 去嘗試各種改動，因為你知道任何時候都能「倒帶」回安全的版本。
接下來，就讓我們一起認識 Git 的核心概念，與有哪些實用的功能吧：）
▍Git 的基本概念
在 Git 裡有幾個常見的名詞，值得先認識一下。
Repository：你的專案資料夾
Repository，通常簡稱 Repo，意思是被 Git 管理的專案資料夾。當你在一個資料夾裡啟用 Git（也就是執行 git init），這個資料夾就變成了一個 Repo。從這一刻起，Git 就會開始追蹤這個資料夾裡所有檔案的變動。
你可以把 Repo 想成一本附帶完整修改紀錄的筆記本——不只記了現在的內容，還記了每一次修改的過程。
如果覺得git init感覺有點生硬的話，也可以用口語化的方式，直接對 Claude Code 說：
「幫我在這個專案資料夾建立 Git」
此時 Claude Code 就會執行 git init，幫你把這個資料夾變成一個 Repo。
Commit：儲存當下的進度點
Commit 是 Git 裡最核心的動作，就是把目前的改動儲存成一個紀錄點。
每次 commit，Git 都會把專案當下的狀態記錄下來，附上你寫的說明訊息和時間戳記。未來你隨時可以回到這個紀錄點，從這裡重新再往下做。
如果用遊戲來比喻，commit 就像是手動存檔。你不會每走一步就存，但會在打完 Boss、拿到重要道具的時候存一下。專案也是一樣，每完成一個功能、修好一個 Bug，就值得存一個進度點。
一樣，可以以口語化的方式來請 Claude Code 執行操作：
「這個功能做好了，幫我儲存進度」
Claude Code 就會會把改動加入暫存區（即git add，如同先把要存的東西先放進購物車），然後再建立一個 commit 來完成存檔。
Branch：開一條平行的開發路線
Branch（分支）可以讓我們從主線上分岔出一條路徑，進而可以在上面做實驗或開發新功能，而不影響主線的穩定版本。等嘗試完成沒穩提後，就可以再合併回來。
口話地直接對 Claude Code 說：
「我想試試看加一個深色模式，幫我開一條新的分支來做」
此時，Claude Code 就會建立一條分支，並切換過去。接下來的改動就都會在這條分支上，不會動到主線。
遠端與本地的關係
由於 Git 的操作都是在你自己的電腦上進行的，因此這就是所謂的「本地端」（Local）。而 GitHub 這類平台則是「遠端」（Remote），讓你可以把專案備份到雲端、跟別人協作，或者純粹當作一個異地備份。
對一個人的 Vibe Coding 專案來說，遠端最大的價值就是備份。如果你還沒把專案推到 GitHub，至少本地的 Git 就能幫你做好版本控制。
▍寫好 Commit 訊息，讓每次存檔都有意義
知道了 Commit 是什麼之後，接下來聊一個很容易被忽略，但其實很重要的事：Commit 訊息要怎麼寫。
Commit 訊息就像日記的標題。你不會在日記上只寫「今天做了事」，你會寫「跟客戶開會討論 Logo 定稿」。好的 commit 訊息也是一樣，當自己日後回頭看時，看 Commit 訊息就能知道當時是因為什麼原因做了什麼改動。
用 Conventional Commits 格式來書寫
Conventional Commits 是一種被廣泛採用的 commit 訊息格式，它的做法是在訊息前面加上一個「類型」標籤，讓每筆紀錄的意圖一目了然：
# 格式
類型: 簡短描述這次改了什麼
# 實際範例
feat: 新增深色模式切換按鈕
fix: 修復手機版選單無法關閉的問題
style: 調整首頁標題的字體大小和間距
docs: 更新 README 的安裝說明
refactor: 簡化導覽列的程式碼結構
feat 代表新功能、fix 是修 Bug、style 是樣式調整、docs 是文件更新、refactor 是重構程式碼。光看前綴就能快速掃過歷史紀錄，知道每次改動的性質。
不需要硬記住這些格式名稱，可以跟 Claude Code 說：
「幫我用 Conventional Commits 格式儲存」
它就會自動分析改動內容，產出合適的訊息，然後你可以查看一下 commit 訊息，看其有沒有表達出正確的意思。
把偏好寫進 CLAUDE.md
不過，若每次都要口頭提醒 Claude Code 用什麼格式，感覺不是很聰明。因此我們可以把這種每次都要重複講的偏好設定，寫進 CLAUDE.md 裡。
CLAUDE.md 是放在專案根目錄的設定檔，Claude Code 每次啟動時都會自動讀取。可以把它想成是給 Claude Code 的「工作說明書」，像是 commit 訊息要用什麼格式、協作方式等，都可以寫在裡面來做為 Claude Code 的指引。
# CLAUDE.md 範例
## Git 規範
- commit 訊息請使用 Conventional Commits 格式
- commit 訊息用英文撰寫
- 分支命名使用 前綴/描述 格式（如 feature/xxx, fix/xxx）
## 開發偏好
- 使用繁體中文跟我溝通
- 改動前先跟我確認方向
設定好之後，未來只要說「幫我儲存」，Claude Code 就會自動用 Conventional Commits 格式來寫 commit 訊息，不需要每次再重新覆述一次。
▍透過 Branch 放心做嘗試，不用擔心影響主線
當你的專案已經有一個穩定運作的版本，這時候想加新功能，你會怎麼做？
直接在原本的程式碼上改，當然可以。但如果改到一半發現方向不對，或者改壞了其他功能，要回頭就會比較麻煩。
分支（Branch）就是為了解決這個問題而存在的。
可以把分支想成是在一份文件上按「建立副本」，在副本上怎麼改都不會動到原始版本。如果改得滿意，就把副本的內容合併回去；如果結果不如預期，直接刪掉副本就好，原始版本還是完好如初。
因此在 Git 預設的主分支（main）上，我們應該永遠保持可以正常運作的版本，而其它新功能的開發或嘗試，都在分支上進行。
這樣一來，就能放心地在分支上大膽嘗試各種想法，不用擔心會影響到 main 上已經穩定的成果。
判斷何時該開分支
那具體來說，我們何時應該開個分支呢？
一個簡單的判斷方式是，如果這次的改動，可能會影響到目前正常運作的功能，就值得開一條分支。
像是調整一下按鈕顏色、改個文案，這種小改動直接在 main 上做就好。但如果要加一整個新功能、重新設計介面的樣式，那就值得另開分支來做。
分支的命名方式
最好的分支命名方式，就是能讓人一眼就知道「這條分支在做什麼」。常見的命名慣例是用 前綴/描述 的格式：
feature/dark-mode → 新增一個功能
fix/login-button-crash → 修復某個問題
design/new-landing-page → 設計相關的調整
experiment/ai-chatbot → 試驗性的想法
可以這樣對 Claude Code 說：
「我想加一個深色模式，幫我開一個新的分支來做」
此時，Claude Code 就會建立 feature/dark-mode 分支，並切換過去。你接下來所有的改動都會在這條分支上，不會影響到 main 分支。
做到一半想切換分支？用 Stash 先暫存起來
有時候你正在分支上做深色模式，老闆突然說另一個功能比較急，要你先處理。但深色模式還沒做完，你也不想 commit 一個半成品。這時候就可以用 stash（暫存）。
它會把你目前做到一半的改動先收起來，讓你乾淨地切換到別的分支。等忙完了，再把暫存的東西拿回來繼續做。
此時，你可能會想說，直接 commit 一個半成品不行嗎？可以，只是這樣的話，就很容易讓 commit 的歷史記錄裡多出一堆「做到一半」的紀錄。Stash 就是為了保持 commit 歷史的乾淨而存在的。
但如果是剛開始接觸 Git，想先養成有 Commit 的習慣的話，那麼整潔度也可以之後再要求，也沒有關係。
但若想試試 Stash 功能的話，可以這樣對 Claude Code 說：
「先幫我將目前的進度暫存起來，我要切換到另一個分支」
回來之後，再跟 Claude 說：
「幫我切回剛才的分支，把暫存的東西拿回來」
▍合併分支來整合開發成果
當你在分支上完成了一個功能，確認沒問題之後，就可以把它合併（Merge）回 main分支。
合併的話，有兩種常見的方式：
Merge：保留完整歷程
這是最直覺的合併方式。就像兩條路在交叉口匯合，Git 會保留完整的分支痕跡，讓你清楚看到這些改動是從哪個分支來的。
大部分情況下，用 Merge 就夠了。它的好處是歷史紀錄完整，未來回頭看時，能清楚知道每個功能是怎麼分開開發、又在什麼時候合併的。
Squash and Merge：壓成一筆乾淨的紀錄
如果你在開發過程中留下了很多瑣碎的小 commit，像是修了一個 typo、調整一下間距等，用 Squash and Merge 可以把這些全部壓縮成一個 commit 再合併。
如此最終在 main 上，只會看到一筆乾淨的紀錄，例如：「feat: 新增深色模式」，而不是十幾筆零碎的小改動。
可以這樣對 Claude Code 說：
「我想把 feature/dark-mode 合併回 main，但我在開發過程中有很多小 commit，幫我壓成一個」
此時，Claude Code 就會用 squash merge 來處理。
而如果不確定該用哪種合併方式，也可以直接問 Claude Code：「幫我分析一下，這個分支用哪種方式合併比較適合？」它就會根據你的 commit 數量和內容來給予建議，你再根據說明來選擇比較好的方式就好囉。
當合併時遇到衝突
合併的時候，有時可能會遇到一個狀況是，你在 main 規劃好導覽列的樣式後，但後來在其它分支有動到導覽列的設計。
此時，若你將分支合併回 main 時，Git 就發現同一個地方有兩個不同的版本，它不確定你要用哪一個——這就是合併衝突（Conflict）。
衝突不是壞事，這是 Git 幫我們把關的一環。當發現有衝突時，Claude Code 便會列出衝突的檔案和位置，解釋兩邊各改了什麼，然後問你想保留哪個版本。
因此不需要擔心怕有衝突，而就不敢開分支。有 Claude Code 幫忙，解決衝突的過程比你想像的簡單很多：）
隨手清理分支，讓專案保持整潔
值得注意的是，分支在合併後並不會自動消失。雖然 Git 會標示哪些分支已經合併，但隨著功能越做越多，分支清單還是會越來越長、看起來越來越雜。
因此，可以在合併完成後順手刪除用完的分支。刪除分支後並不會因此遺失任何資料，因原本的 commit 紀錄都已經存在 main 裡，隨時都能回顧。
當然，如果評估某個功能近期還要微調，這個分支就可以先保留著。或是合併後先觀察一陣子，確認 main 運作正常再刪除也不遲。
▍用 .gitignore 保護你的 API 金鑰
在 Vibe Coding 的過程中，專案很可能會用到第三方服務的 API 金鑰或密碼，這些機密資訊通常會存在一個叫 .env 的檔案裡。
值得注意的是，這個檔案是絕對不能被 Git 記錄到的。因為一旦 commit 之後推送到 GitHub，你的金鑰就等於公開在網路上了。網路上有很多駭客寫的機器人在 24 小時自動掃描 GitHub，只要金鑰一曝光，幾秒鐘內就可能被盜刷或濫用。
更麻煩的是，Git 會記住所有事情，就算事後從資料夾裡刪掉那個檔案，歷史紀錄裡還是找得到。
.gitignore 就是用來防止這件事的。它是一份告訴 Git「請忽略這些檔案」的清單，只要把 .env 加進去，Git 就不會追蹤它。
在實際操作上，可以對 Claude Code 說：
「幫我建立一個 .gitignore，確保 .env 不會被追蹤」
此時，Claude Code 就會幫你建立 .gitignore。而除了 .env 之外，它還會根據你的專案類型，自動加入其他該忽略的系統暫存檔或套件資料夾。這些可以不需要特別記，交給 Claude Code 處理就好。
確認 .env 是否有被保護的方法
如果不確定 .env 有沒有被保護到，有兩種方式可以確認：
直接問 Claude Code：「幫我確認一下，
.env有在.gitignore裡面嗎？」如果沒有，它可以幫你加上。自己打開來看：
.gitignore其實就是一個純文字檔，放在專案的根目錄裡。你可以用任何文字編輯器打開它，只要裡面有一行寫著.env就安全了。
而如果是已經不小心把 .env 傳上 GitHub 了，最快也最安全的補救方法不是去改 Git 紀錄，而是立刻去那個第三方服務的後台，把那把 API 金鑰作廢（Revoke），然後重新申請一把新的，就樣就不用怕原本的 API 金鑰會被濫用。
總結來說，我們可以建立一個習慣是把「設定 .gitignore」當作每個新專案的起手式。一開始就先讓 Claude 幫你把這層防護網架好，確保接下來 Vibe Coding 旅程能既順暢又安全。
▍結語
Git 一開始聽起來或許有些複雜，但其實可以先從了解幾個關鍵動作來開始：commit 儲存進度、branch 開分支來嘗試新想法、merge 整合結果，以及用 .gitignore 保護機密資訊。
特別是搭配 Claude Code 後，可以不需要硬記要打什麼指令，只要像對話一般來這樣說：「幫我儲存一下現在的進度」、「開一條新分支來寫這個功能」，Claude Code 就能輕鬆搞定。
而這也表示，其實我們真正該把精力花在理解「什麼時候該做什麼事」。知道何時該留紀錄、可以如何該開展新點子等，這些才是讓 Vibe Coding 專案順利推進的關鍵。
掌握了 Git，等於為你的專案拿到了一把無限次數的「時光鑰匙」。握有了這把鑰匙，就能放心地透過 Claude Code 來去打造任何新奇的想法，因為你知道就算不小心搞砸了，隨時都能讓時間倒流，回到最初完好的狀態：）