AI 改壞程式怎麼救？非工程師的 GitHub 入門與 Vibe Coding 版本管理指南
用 AI 做網站或小工具，最讓人緊張的時刻，往往是原本正常的功能突然壞掉，請它修一下，又改出更多問題，最後連哪個版本能用都說不清楚。
Vibe Coding 想要改得放心，先要有能確認的版本紀錄，Git 負責保存程式變更，GitHub 提供遠端儲存庫與協作流程。你不必先背熟指令，但要能回答改動存在哪裡、是否進入主分支，以及復原會影響哪些內容。
這篇 GitHub 入門指南以能讀寫專案檔案的 AI 開發工具為情境，若使用 Lovable 這類 AI App Builder，也要先確認平台的版本紀錄、GitHub 同步與部署各由誰管理，避免把不同系統的「已儲存」當成同一件事。
Git 和 GitHub 差在哪？先分清楚存檔與提交
Git 是版本控制工具，可以在自己的電腦上運作，GitHub 則是託管 Git 儲存庫的平台，讓程式可以放到遠端、比較修改內容，再透過 Pull Request 討論與合併，使用 Git 不一定要使用 GitHub，也可以搭配其他託管平台。
按下編輯器的儲存，只代表檔案寫入磁碟，commit 才是建立一筆 Git 提交紀錄，通常記錄的是放入暫存區的內容，也就是這次選定要提交的變更，尚未加入版本控制、被忽略，或還沒選入暫存區的修改，不會因為做了一次 commit 就全部被保存，細節可參考 Git 官方的變更記錄說明。
因此，第一次請 AI 接手專案，可以先讓它檢查是否已有 Git 紀錄、目前在哪個分支，以及有哪些未提交的檔案，接著在功能確認正常後建立一筆容易辨識的提交，例如「完成登入表單驗證」，再開始下一輪修改。
先檢查這個專案的 Git 狀態，列出目前分支、最新提交，以及已修改和未追蹤的檔案。說明這次應保存哪些內容，排除密碼與無關檔案，再建立一筆清楚描述功能狀態的提交。
Commit、push、PR、merge，是不同的完成狀態
commit 留在本機，不代表遠端已有相同內容，push 把提交送到指定的遠端分支，也不代表改動已進入主分支，PR 是提出合併變更的請求，merge 才會把變更整合到目標分支。
採用 PR 流程時，要檢查 PR 指向哪個目標分支、狀態是 Open、Closed 還是 Merged，Closed 只表示請求關閉，不能直接理解成已合併，部分專案允許直接推送主分支，因此 PR 是一種協作與審查流程，不是所有 Git 專案的必經步驟，可參考 GitHub 的 Pull Request 說明。
還有一個容易漏掉的狀況：PR 已合併後，又把新提交推到原來的功能分支，push 可能成功，但後來的提交不會自動補進那次已完成的合併，要另外確認是否需要新 PR，或依專案流程再次整合。
儲存庫更新與網站上線也要分開驗收，GitHub 上看得到程式，不代表正式網站正在執行那一版，部署平台可能使用另一個分支，也可能建置失敗。像 用 Claude Code 製作網站的完整工作流，最後仍要回到實際網址確認功能與畫面。
上傳前檢查機密，補上 .gitignore 不會抹掉歷史
API 金鑰、資料庫密碼、含憑證的設定檔，不應直接放進提交，請 AI 同時檢查檔案清單與即將提交的內容，並依專案需要設定 .gitignore。私有儲存庫也應避免存放這些機密。
.gitignore 主要處理尚未追蹤的檔案，已經被 Git 追蹤的檔案，不會因為新增忽略規則就自動停止追蹤，既有提交中的內容也仍然存在，這是 Git 官方文件 明確區分的行為。
如果金鑰已經外洩，第一步是到服務提供者那裡撤銷或更換金鑰，再處理儲存庫內容與歷史，只把目前檔案刪掉，不能讓舊金鑰失效。歷史清理還可能影響協作者，應依 GitHub 的機密資料處理指引 安排。
換電腦與同步協作，clone 和 pull 各做什麼？
從 GitHub 下載 ZIP，取得的是某個版本的檔案快照，要延續既有 Git 開發流程，通常會用 clone 取得儲存庫與版本歷史，讓本機能追蹤遠端。只拿到 ZIP，不能直接假設原來的 Git 設定和提交紀錄也都在。
已有本機儲存庫後，pull 會抓取遠端變更，再依設定整合到目前分支，例如使用 merge 或 rebase，它不只是把遠端檔案下載覆蓋過來，同步前先確認分支、遠端，以及本機尚未提交的內容是否妥善保存，操作語意可查 git pull 官方文件。
發生衝突時，讓 AI 說明兩邊原本要保留的行為，再決定如何整合，即使沒有出現文字衝突，也可能發生功能上的衝突。例如一邊調整登入流程，另一邊改了權限判斷，合併成功後仍要把兩個情境都測過。
兩個 AI 同時改專案，先分開實際工作目錄
同時開兩個 AI 視窗，不等於它們各有一份檔案。如果都在同一個工作目錄，一方存檔、切換分支或整理暫存內容，仍可能干擾另一方。只有不同任務名稱或分支名稱，也不足以證明工作檔案已隔離。
Git worktree 可以讓同一個儲存庫擁有多個工作目錄，分別檢出不同分支。
例如一份處理登入，一份調整版面，完成後再逐一審查與合併。它們有各自的工作檔案與部分狀態，但仍共享儲存庫資料及部分參照，不能把它當成完全獨立的安全沙箱。詳見 Git worktree 官方文件。
要確認的，是每個 AI 實際使用的 worktree 根目錄與分支，若測試會共用資料庫、輸出位置或服務連接埠，也要另外安排。想把這套分工放進操作介面，可以延伸閱讀 Orca ADE 的多 Agent 與 worktree 工作方式。
開始平行開發前，請列出每個任務的實際 worktree 根目錄、分支及修改範圍，確認彼此不會寫入同一份工作檔案，並檢查測試資料庫、輸出資料夾與連接埠是否共用。完成後逐一提交、驗證與合併。
AI 改壞了怎麼復原？先辨認改動在哪個階段
先暫停繼續修改，保留目前差異，再確認錯誤改動是否已提交、推送或合併。直接對 AI 說「全部還原」，容易連原本想保留的工作也一起丟掉。
restore 用來恢復指定檔案的內容，但來源要說清楚，未指定來源時，一般工作目錄還原預設取自暫存區，不一定是最後一次提交，使用 --staged 則是調整暫存區，預設來源為 HEAD，並不等於刪除工作檔案，會覆蓋工作目錄的還原操作可能丟失未提交修改，執行前要確認路徑、來源與備份。參考 git restore 官方文件。
revert 則是用新的提交，抵銷指定舊提交帶來的變更，它保留既有歷史，常用在已分享的提交，但可能遇到衝突，也不代表整個專案必然回到某個舊時間點，若要修正遠端主分支，新的復原提交仍需依流程推送、合併與部署。參考 git revert 官方文件。
檔案突然不見，也不能立刻認定永久刪除，可以先查是否切到別的分支、內容是否被放進 stash，或是否有提交紀錄與編輯器備份，不過，從未提交也沒有其他備份的內容，Git 並不保證能救回。
先不要執行會丟棄修改的操作，請查明問題改動是否已提交、推送與合併，保留目前差異，列出建議復原的檔案、來源版本及會失去的內容，再說明應使用檔案還原、復原提交或其他方法，並列出復原後的驗證項目。
Diff 要看什麼？先問比較的是哪兩個版本
看到大量新增或刪除行數，先確認比較範圍，GitHub PR 採用三點差異比較，從共同祖先到功能分支目前版本，重點是這個分支引入了什麼，直接比較兩個分支的最新狀態，得到的內容可能不同，尤其主分支已經往前更新時，參考 GitHub 的分支差異說明。
行數只是定位問題的線索，格式調整、自動產生的檔案或重新命名，都可能讓變動看起來很大。
更實際的檢查是：改動是否符合這次需求、是否碰到無關檔案，以及重要功能有沒有測過。
把「完成了嗎」改成一份可查證的交付回報
對非工程背景的人來說，最有用的習慣，是要求 AI 在每次交付時附上可以追查的狀態。下
面這段可以直接加入日常任務：
請用非工程師看得懂的方式回報這次交付，列出本機分支與最新提交、遠端分支是否已包含這次變更、PR 連結與合併狀態．若有多個 AI，列出各自的實際工作目錄。說明差異比較的基準、改了哪些檔案，以及哪些測試或操作情境已通過。若涉及網站上線，另附部署結果與實際驗證網址。沒有完成的步驟請明確標出。
從下一次小修改開始，先保存已確認正常的狀態，再讓 AI 動手。完成後看差異、驗證功能，最後確認遠端與部署狀態。這套習慣建立起來，才能在出錯時知道從哪裡查，而不必每次都靠重做。
GitHub 與 Vibe Coding 常見問題
不會寫程式，也需要學 Git 嗎？
使用 AI 修改專案時，至少應理解提交、分支、遠端與復原的差別，指令可以交給工具執行，但仍要能確認保存了什麼，以及哪些步驟尚未完成。
Commit 成功就代表已上傳 GitHub 嗎？
不代表。commit 建立本機提交，push 才會把提交送到指定遠端分支，是否合併到主分支，以及是否部署成功，都要另外確認。
PR 已合併後，再 push 就會更新主分支嗎？
不會自動更新。推到原功能分支的新提交，不會追加到先前已完成的合併，應依專案流程建立新 PR 或再次整合，確認新變更已進入目標分支。
Restore 和 revert 有什麼不同？
restore 恢復指定位置的檔案內容，必須確認來源與是否覆蓋未提交修改。revert 以新提交抵銷舊提交的變更，保留歷史，但可能需要處理衝突。
Worktree 可以完全避免兩個 AI 互相干擾嗎？
不能保證。不同 worktree 可分開工作檔案，但仍共享部分 Git 資料，外部資料庫、服務與輸出位置也可能共用，應確認目錄、分支與執行環境的分工。
近期留言