如何搭配 AI 建置的應用程式使用 Git

要搭配 AI 建置的應用程式使用 Git，請把專案連接到 Git 儲存庫，每次有效的修改後都提交，用一行訊息說明改了什麼，並用 .gitignore 把機密資料排除在外。高風險的工作請使用分支；如果別人改過程式碼，再次提示前先拉取；AI 弄壞東西時，請回到最後一個正常的提交，而不是在混亂的版本上繼續提示。

Git 是版本控制：保存程式碼每一個已儲存版本的歷史紀錄。GitHub 則是在網路上存放 Git 儲存庫的網站。如果這些名詞對你來說還很陌生，可以先看什麼是 GitHub。本指南談的是，當 AI 大部分時間都在寫程式碼時，哪些習慣能讓 Git 真正發揮作用。

為什麼 AI 時代 Git 更重要

AI 一次可能改動二十個檔案。這很快，但也代表一次提示就可能悄悄弄壞你昨天測試過的功能。Git 提供：

• 一條退路。 任何已提交的版本都可以還原。
• 修改紀錄。 你可以看出某次提示實際改了哪些檔案、哪些行。
• 建置工具之外的副本。 你的程式碼存放在你自己掌控的地方。
• 標準化的交接方式。 任何開發者、主機或工具都能從 Git 儲存庫開始工作。

步驟一：連接儲存庫

在 GitHub 或類似服務上建立一個儲存庫（通常設為私人），並把你的專案連接上去。支援 Git 的 AI 應用程式建置工具大多會在設定頁面提供「連接 GitHub」按鈕。如果你的工具沒有這個功能，可以匯出程式碼後自行推送，或請開發者幫你設定一次。

第一次推送前，請確認儲存庫會忽略不應該出現在裡面的東西：

檢查 .gitignore 檔案。確認它排除了 .env 檔案、node_modules、建置輸出資料夾，以及所有含有機密資料的檔案。告訴我你新增了哪些項目。

步驟二：每次有效的修改後都提交

提交（commit）就是附帶訊息的一份已儲存快照。最重要的習慣是：當某件事情能正常運作時就提交，然後才要求下一件事。

1. 針對一項修改進行提示。
2. 在預覽中檢查結果。
3. 如果正常運作，就提交（或同步），並附上訊息。
4. 然後再繼續下一步。

小的提交代表當有東西壞掉時，你知道是哪一項修改造成的，而且復原它時不會連帶丟掉其他工作。

步驟三：寫下之後還看得懂的訊息

好的訊息要用一行說明改了什麼、為什麼改：

• 好：在訂單頁面新增 CSV 匯出
• 好：修正預約表單在晚上 6 點後拒絕時間的問題
• 沒有用：update、changes、fix stuff

你也可以請 AI 幫你寫：

用一行總結自上次提交以來的變更，以動詞開頭，不超過 70 個字元。

步驟四：高風險的工作使用分支

分支是一條獨立的工作線。你可以在分支上嘗試某件事，如果行不通，就放棄它，而不影響主要版本。

以下情況請使用分支：

• 修改幅度很大（例如重新設計、新的付款流程、資料庫變更）。
• 有其他人正在處理同一個應用程式。
• 你希望在上線前讓別人審查這項修改。

工作完成並測試後，就會**合併（merge）回主要分支。在 GitHub 上，通常會透過拉取請求（pull request）**進行，也就是一個顯示變更內容以供審查的頁面。如果你的建置工具只同步一個分支，開發者可以在 GitHub 端管理分支。

步驟五：安全地復原

當某次提示弄壞了應用程式，請克制住在上面再連續提示五次的衝動。回到最後一個正常的版本，然後用更清楚的提示再試一次。

• 在建置工具中： 如果有檢查點或還原功能，就使用它。
• 在 Git 中： git revert 會建立一個新的提交來撤銷舊的提交，歷史紀錄保持完整。對於其他人可能已經拉取過的程式碼，這是安全的選擇。
• 避免在共用分支上使用 git push --force，除非你完全清楚原因。它會為所有人改寫歷史紀錄。

如果你不確定，可以這樣問：

上一次修改弄壞了登入頁面。請比較它與上一個提交相比改了哪些檔案，並說明每個變更做了什麼。先不要改任何東西。

步驟六：提示前先拉取

如果開發者或其他工具在 GitHub 上改了程式碼，AI 建置工具不會知道，直到你把那些變更**拉取（pull）**進來。在舊的程式碼上提示，會造成衝突並遺失工作。

• 每次工作階段開始時都拉取。
• 約定好誰負責編輯哪些部分，避免雙方同時修改同一批檔案。
• 如果出現合併衝突（同一行被兩邊修改），請開發者或 AI 來解決，並說明選擇的原因。

範例提示

開始之前：自上次工作階段以來，儲存庫有哪些變更？請總結這些提交。

只做下一項修改：在每張發票上新增「複製」按鈕。其他部分都不要動，這樣我可以單獨提交。

檢查 Git 中（包括過去的提交）是否有 API 金鑰、密碼或 .env 檔案被追蹤。只回報檔案名稱，不要回報內容。

常見錯誤

• 提交機密資料。 金鑰一旦進入 Git 歷史紀錄就已經外洩，即使之後刪除檔案也一樣。請重新產生金鑰。
• 一週只提交一次大型變更。 你無法只復原其中一項修改，而不把全部都復原。
• 訊息只寫「update」。 歷史紀錄會變得無法用來找出是什麼東西壞掉。
• 在過時的程式碼上提示。 如果別人也在編輯，請先拉取。
• 為了修正錯誤而強制推送。 這可能會抹掉其他人的工作。請改用還原（revert）。
• 提交 node_modules。 它很大，而且反正都會根據鎖定檔案重新產生。

檢查清單

• 專案已連接到私人儲存庫。
• .gitignore 排除了 .env、node_modules、建置輸出和所有機密資料。
• 每次有效的修改後我都會提交。
• 提交訊息用一行說明改了什麼。
• 大型或高風險的修改會放在分支上，並經過審查。
• 如果別人也在編輯程式碼，我會在提示前先拉取。
• 我使用檢查點或 git revert 來復原，而不是強制推送。
• 任何曾經被提交的金鑰都已重新產生。

在 Mythex 上使用 Git

Mythex 會在每次成功的代理程式回合後儲存一個 Git 檢查點，而**還原到此處（Revert to this point）**會把專案回復到該檢查點，也就是第五步所說的建置工具端復原功能。請參閱不用重新建置也能持續修改。

在 Pro 方案中，GitHub 同步可以在專案設定中連接儲存庫，讓你與它進行推送與拉取；匯出則會下載專案，並且不包含機密資料和 node_modules。請參閱 GitHub、匯出與匯入。在把專案交給開發者之前先連接 GitHub，交接會簡單很多，請參閱如何與開發者合作處理 AI 建置的應用程式與如何匯出並自行架設 AI 建置的應用程式。

常見問題