為什麼 Vibe Coding 必學 Git 和 GitHub？非工程師也能看懂的存檔與復原指南

我相信你的電腦也可能出現過這些檔案：

plaintext

報告_v1.docx
報告_v2.docx
報告_final.docx
報告_final_修正版.docx
報告_final_真的最後一版.docx

最麻煩的不是檔名難看，而是：

你不知道「final」和「final_修正版」究竟相差甚麼。
每個檔案看起來都可能有用，所以一個也不敢刪。
真正需要舊版本時，只能逐個打開尋找。
所謂「最後一版」，永遠可以再多一個最後一版。 Vibe Coding 的情況更加危險。你只說一句「幫我把登入改成 Google 登入」，AI 可能已經同時修改多個檔案。等你發現網站無法使用，原本正常的版本可能早已被覆蓋。所以，Git 並不是工程師才需要的工具。愈不懂程式碼，反而愈需要一個可以返回之前版本的方法。 這篇不會要求你背 Git 指令。你只需要知道甚麼時候要叫 AI 保存，以及出事時不要叫它繼續亂試。

一、Git 是存檔，GitHub 是雲端存檔

先用最簡單的方法理解：

Git：保存在目前電腦上的遊戲存檔。

GitHub：把遊戲存檔再放到網上保管。只有 Git，改壞時可以返回舊版本，但電腦壞掉仍可能一起失去。只有 GitHub，而平日沒有建立版本，也沒有東西可以讓它替你保管。所以兩者通常一起使用：

先用 Git 保存一個版本。
再把這個版本上傳至 GitHub。 GitHub 還有另一個用途：Vercel、Netlify 等上線服務可以從 GitHub 取得專案；換電腦或交給別人處理時，也可以從同一個地方接續。

二、只需要認得四個詞語

AI 處理 Git 時，經常會說以下四個英文詞。你不用懂背後原理，只要知道它們代表甚麼。

Commit：保存一個版本

Commit 就像按下「儲存進度」。它會記錄當時的專案狀態，以及一句「這次修改了甚麼」。幾天後想找回舊版本時，這句說明就是最重要的線索。 生活版例子：客戶只是想把字放大一點 想像你用 Canva 做好一張品牌合作圖，字體、相片和顏色都已經調整完成。客戶忽然說：「標題可以再大一點嗎？」有經驗的人不會直接在唯一的成品上修改，而會先複製一份，再嘗試新的排版。因為改了十分鐘後，客戶很可能又說：「好像原本那版比較好。」 Commit 就是那句「這版先替我保留」。它不是發布，也不是上線，只是確保剛才的成果不會消失。

Push：把版本上傳至 GitHub

Commit 只保存在目前的電腦。 Push 才是把已保存的版本上傳至 GitHub。可以把它理解成：Commit 是按儲存，Push 是打開雲端備份。 生活版例子：相片仍在手機，不等於已有備份 Commit 很像相片仍然保存在手機裏；Push 則像把相片同步至 iCloud。如果手機跌進水裏，而相片從未上傳，不能怪 iCloud 沒有替你保存。GitHub 也是一樣：你沒有 Push，它便不知道電腦裏還有一個最新版本。所以 Commit 是「我保存了」，Push 才是「即使這台電腦出事，我還有另一份」。

Branch：建立一個試玩版本

如果你想大改首頁，又擔心改壞，可以先建立 Branch。它像把目前正常版本影印一份，在副本上任意嘗試。成功後再放回正式版本；失敗便放棄副本，原本的版本仍然保留。 生活版例子：同一張廣告圖要做三個版本 品牌客戶經常會說：「可以做一個少女感版本，再做一個黑金高級版本嗎？」正常人不會把粉紅色、蝴蝶結、黑色背景和金色字體全部疊在同一張 Canva 設計上，而會先複製原稿，再分開製作不同版本。 Branch 就是這些試稿。每一版都可以大膽修改，但真正要發布的 Main 仍然保持乾淨。最後選中哪一版，才把它放回正式版本。

Main：目前的正式版本

AI 常會把主要版本稱為 main。你不需要特別操作它，只要知道：進行風險較高的實驗時，不要直接在唯一的正式版本上亂改。

三、Git 只能救你曾經保存的東西

安裝 Git 不等於自動得到保護。就像玩遊戲三小時也沒有存檔，角色死掉後不可能返回五分鐘前。Git 只能帶你返回已經建立過的 Commit。最簡單的習慣是：每完成一個看得懂的小階段，便保存一次。 例如：

登入功能已經可以使用。
表單可以成功送出。
手機版畫面已經修好。
新增的按鈕可以正常操作。不用等整個網站完成才保存，也不要每改一個字便保存。只要問自己：「如果下一步改壞了，我會不會想回到現在？」如果答案是會，現在就是建立 Commit 的時候。可以直接對 Claude Code 說：

我剛完成了「（簡單描述這次完成的內容）」。請先確認這部分可以正常使用，再整理這次修改了甚麼。檢查沒有秘密資料後，提出一個版本說明，等我確認後再建立 Commit 並 Push 至 GitHub。有存檔的人，才敢放心叫 AI 大改。因為不喜歡結果時，至少知道可以回去。

四、唯一絕對不要上傳的東西：你的鑰匙

搬家時，你會把家具放進紙箱，卻不會把家門鑰匙貼在紙箱外面寄走。程式專案也有自己的「鑰匙」：

API key
Token
密碼
資料庫登入資料
其他服務提供的秘密憑證這些資料經常放在名為 .env 的檔案。你不需要理解它怎樣運作，只要記住：真正的 .env 通常不應上傳至 GitHub。 生活版例子：Private Repository 不是保險箱 有人會想：「我的 GitHub 專案已經設成 Private，放密碼應該沒有問題吧？」 Private Repository 比較像 Instagram 的 Close Friends：看到的人少一點，但它不是密碼保險箱。你不會把提款卡密碼放進 Close Friends，也不應把 API key 或 .env 上傳至 GitHub。
第一次保存或上傳前，可以說：

請先檢查這個專案有沒有 .env、API key、Token、密碼或其他秘密資料。不要在畫面顯示完整內容，也不要把它們加入 Git。先告訴我檢查結果，等我確認後才保存及上傳。如果秘密已經上傳，刪除檔案並不代表沒有人看過。第一件事應該是到相關服務的設定頁面，讓舊鑰匙失效並更換新鑰匙，再處理 GitHub 上的紀錄。詳細步驟可參考 GitHub 的敏感資料處理指引。 💡 Git 主要保存專案檔案，不會自動備份網上資料庫、使用者上傳的圖片或第三方服務內的資料。重要資料仍然需要另外備份。

五、第一次設定 GitHub

第一步：註冊 GitHub 帳號

前往 github.com 註冊帳號，記下 Username，並完成電郵驗證。

第二步：如果不想公開私人電郵，複製 noreply 地址

每次 Commit 都會記錄作者名稱及電郵地址。如果不想讓私人電郵跟着公開紀錄出現，可以使用 GitHub 提供的 noreply 地址。它不是另一個收件箱，只是一個用來代表你身分的私隱地址。尋找方法：

登入 GitHub。
按右上角頭像，進入 Settings。
選擇 Emails。
開啟 Keep my email addresses private。
複製頁面顯示的 noreply 地址。以頁面實際顯示的地址為準，不需要自己猜格式。GitHub 官方說明

第三步：讓 Claude Code 協助完成設定

在專案資料夾內開啟 Claude Code。如果已經開啟，也不用特意關掉；只要確認它目前正在處理正確的專案資料夾。然後貼上：

這是我要使用 Git 保存的專案。請先檢查這台電腦是否已經安裝 Git，以及我是否已登入 GitHub；如果尚未完成，請逐步指導我。作者名稱使用我的 GitHub Username「（填上 Username）」，電郵使用「（貼上 GitHub 顯示的 noreply 地址）」。再檢查哪些檔案不應上傳，尤其是 .env、密碼和自動產生的大型資料夾。不要顯示秘密內容，也不要立即上傳。請先列出你準備保存的檔案及步驟，等我確認後才建立私人 GitHub 專案、保存第一個版本並上傳。第一次的提示詞稍長，是因為它同時處理帳號、私隱、秘密資料和第一個版本。完成後，日常使用會簡單很多。

六、我不想學 Git，我只是不想把網站弄不見

如果你看到一長串 Git 名詞便開始頭痛，放心，日常使用不需要全部背下來。你只需要記住五個常見情境。

開始修改前：先問「現在可以動嗎？」

每次準備叫 Claude Code 修改專案前，先說：

我要開始修改專案。請先幫我確認目前是否有尚未保存的改動，以及 GitHub 上是否有較新的版本。現在只檢查，不要修改任何檔案。最後直接告訴我是否可以安全開始。如果你只有一台電腦，而且整個專案只有你一個人處理，通常不會出現版本互相碰撞的問題。這一步主要是避免上一次改到一半便離開，今次又把新工作直接疊在上面。

完成一小部分：立即保存

例如登入功能已經可以使用、表單已經可以送出，或者手機版畫面已經修好，便可以說：

我剛完成了「（簡單描述內容）」。請先測試這部分是否正常，再整理這次修改了甚麼。確認沒有 .env、密碼或其他秘密資料後，提出一個版本說明，等我確認後再建立 Commit 並 Push 至 GitHub。把它想像成遊戲存檔：完成一個小關卡便保存，不要玩了八小時才第一次存檔。

改壞了：先不要再請 AI「試一次」

最危險的情況不是第一次改壞，而是改壞後不斷叫 AI「再試一次」。它可能愈改愈多，最後連原本的問題在哪裡也找不到。 這就像自己剪壞瀏海 自己剪瀏海最危險的，通常不是第一刀，而是第一刀剪歪後，心想「再修一下應該可以」。左邊修完覺得右邊太長，右邊修完又覺得左邊不對，最後瀏海愈來愈短。 Claude Code 改壞網站也是一樣。你原本只想把按鈕變圓，結果手機版選單消失；接著再請它嘗試五次，問題便可能由一個按鈕變成十個檔案。所以出事後最重要的不是立即修好，而是先停手，至少先弄清楚第一刀剪錯了哪裡。

先貼上這句：

剛才修改後，「（描述哪個功能壞了）」。請立即停止新增修改。先檢查哪些內容尚未保存、哪些已經建立 Commit、哪些已經 Push 至 GitHub，並列出受影響的檔案。現在不要還原、保存、上傳或刪除任何內容，等我確認後才進行下一步。你不用先弄懂應該使用哪一條 Git 指令。只要看 Claude Code 的檢查結果，再選擇下面最接近的情況。

情況一：剛才的修改還沒有 Commit

這就像在 Canva 改壞設計，但還沒有按下「建立副本」。先保留現況，才不會在還原時把其中有用的部分一起丟掉。

請先安全保留目前尚未 Commit 的修改，不要刪除。再提出回到上一個正常版本的方法，並列出畫面上哪些內容會暫時消失。等我確認後才執行。

情況二：錯誤版本已經 Commit，甚至已經 Push

既然錯誤版本已經進入紀錄，最安全的做法通常不是假裝它從未存在，而是新增一個版本把問題改回來。

這個錯誤版本已經 Commit／Push。請找出最可能造成問題的版本，告訴我它修改了甚麼。不要刪除歷史，也不要強行覆蓋 GitHub；請提出以一個新版本抵銷錯誤的方法，等我確認後才執行。

情況三：只有一個檔案壞了

如果只有 Header 壞了，沒有必要連已完成的付款頁面也一起退回。

請只檢查「（檔案名稱或功能）」，比較它與上一個正常版本，並告訴我還原後有哪些尚未保存的內容會消失。其他檔案不要修改，等我確認後才還原。

情況四：檔案被刪除了

「（檔案名稱）」不見了。請確認它以前是否曾經保存於 Git，找出最後一個仍然包含它的版本。先顯示你找到的版本及會影響的內容，等我確認後才取回檔案；其他檔案不要修改。 Git 只能找回曾經 Commit 的檔案。假如它從未保存過，便像拍完相片後沒有按下儲存，Git 也無法憑空變回來。

情況五：不知道從哪一次開始出錯

請列出最近的版本時間、說明和主要修改，選出三個最可能仍然正常的版本。請在另外建立的試驗版本中逐一檢查，不要讓 Main 倒退，也不要覆蓋目前內容。先說明計劃，等我確認後才執行。

情況六：試驗版本失敗，或合併時出現衝突

請比較試驗版本與 Main，列出兩邊各自修改了甚麼，以及哪些位置出現衝突。不要自行選擇、合併或刪除任何版本；逐項向我解釋，等我決定。如果只是看不懂錯誤訊息，直接把完整內容貼給 Claude Code，再補一句：請先用一般人能理解的方式解釋這個錯誤，列出三個最可能的原因，以及你準備進行哪些只讀檢查。不要先修改程式碼。 🛟 無論是哪一種事故，都記住四件事：先檢查、說明影響、不要自行刪除、等我確認。 這四句比背熟任何 Git 指令更重要。

準備換電腦：離開前先上傳

GitHub 不會自動知道你在舊電腦修改了甚麼。只有已經 Commit 並 Push 的內容，另一台電腦才看得到。 GitHub 不會讀心 星期五在公司電腦把首頁改好，星期日在家打開另一台電腦，卻發現甚麼也沒有。這通常不是 GitHub 壞了，而是星期五完成後沒有 Push。 GitHub 不會偷偷走進舊電腦拿走最新版。離開一台電腦前先 Commit 和 Push，另一台電腦才有東西可以接續。離開舊電腦前說：

我要稍後在另一台電腦繼續。請幫我確認目前修改可以正常使用，檢查沒有秘密資料，然後保存並上傳目前版本至 GitHub。完成後告訴我使用的是哪一個 Branch。到了另一台電腦，再說：我要接續另一台電腦的工作。請先取得 GitHub 上的最新版本。如果這台電腦有尚未保存的修改，立即停止，不要覆蓋任何內容。如果是全新的電腦，可以說：請把這個 GitHub 專案下載至新的資料夾，然後告訴我還需要安裝或設定甚麼才能運行。.env 和密碼不要上傳至 GitHub，請告訴我哪些私人設定需要另外加入。

想試一個大改動：先建立 Branch

Branch 可以理解成一個「試玩版本」。你可以在裏面重新設計首頁、改登入方式或嘗試新功能。成功才放回正式版本；失敗便放棄，不會直接破壞原本的網站。

我想嘗試「（描述改動）」，但不確定能否成功。請先保存目前正常版本，再建立一個新的 Branch。接下來的修改只在試玩版本內進行，不要直接修改 Main。至於怎樣把成功的結果放回 Main，等實驗完成後再請 Claude Code 一步一步說明即可。

七、一頁速查

現在的情況	只需要說
準備開始修改	先檢查現在是否可以安全開始，不要改任何檔案。
完成一小部分	先確認可以使用，再保存並上傳。
剛才改壞了	立即停手，先告訴我改了甚麼，不要刪除。
準備換電腦	舊電腦先保存並上傳；新電腦才取得最新版本。
準備大改	先保存正常版本，再建立 Branch 試驗。

最後只要記住：

Commit：保存。
Push：上傳。
Branch：試玩版本。
Main：正式版本。

其他名詞遇到時再問 AI，不需要一次學完。

寫在最後

Git 的目的不是把你訓練成工程師。它真正提供的，是一種放心嘗試的底氣：你可以叫 AI 改整個版面、重做一項功能，甚至嘗試一個未必成功的主意，因為你知道原本正常的版本仍然存在。對 Vibe Coding 使用者而言，最重要的不是背指令，而是養成四個習慣：

開始前先檢查。
完成小階段便保存。
保存後記得上傳。
改壞後立即停手。

你不需要知道 Git 的所有答案，只需要確保每次出事時，仍然有一個可以返回的地方。