點樣用 Git 管理 AI 建立嘅 App

要用 Git 管理 AI 建立嘅 App，就要將專案連接到 Git 儲存庫，每次有效嘅改動之後都 commit，commit 訊息寫一句講清楚改咗乜，並用 .gitignore 將機密資料排除喺外。遇到風險較高嘅改動就用分支處理；如果其他人改過程式碼，再用 AI 之前先 pull。AI 搞砸咗嘢時，就返回最後一個正常嘅 commit，唔好喺一團亂嘅程式碼上面繼續叫 AI 改。

Git 係版本控制工具，記錄程式碼每一個已儲存嘅版本。GitHub 係一個喺網上儲存 Git 儲存庫嘅網站。如果你對呢啲未熟，可以先睇什麼是 GitHub。本指南講嘅係一啲習慣，令 Git 喺 AI 寫咗大部分程式碼嘅情況下都好有用。

點解 AI 時代 Git 更加重要

AI 一個回合就可以改二十個檔案。咁樣好快，但都代表一個 prompt 可能悄悄弄壞你尋日先測試過嘅嘢。Git 俾你：

• 一條退路。 任何已 commit 嘅版本都可以還原。
• 改動紀錄。 你可以清楚睇到一個 prompt 改咗邊啲檔案同邊啲行。
• 建置工具以外嘅副本。 你嘅程式碼存放喺你自己可以控制嘅地方。
• 標準嘅交接方式。 任何開發者、主機或者工具都可以基於 Git 儲存庫工作。

第一步：連接儲存庫

喺 GitHub 或者類似服務建立一個儲存庫（通常設為私人），然後將你嘅專案連接過去。大部分支援 Git 嘅 AI App 建置工具都透過設定頁面嘅「連接 GitHub」按鈕完成。如果你嘅工具冇呢個功能，你可以匯出程式碼再自行推上去，或者請開發者幫你設定一次。

第一次 push 之前，確保儲存庫唔會包含唔應該出現嘅嘢：

檢查 .gitignore 檔案。確保佢排除咗 .env 檔、node_modules、建置輸出資料夾同任何包含機密資料嘅檔案。講清楚你加咗乜。

第二步：每次有效改動後都 commit

Commit 就係一個附有訊息嘅已儲存快照。最重要嘅習慣係：有嘢做得啱，就喺要求下一項功能之前 commit。

1. 要求改一樣嘢。
2. 喺預覽度檢查。
3. 如果得，就 commit（或者同步），並寫好訊息。
4. 然後再繼續。

Commit 細啲，出問題時你就知道係邊個改動搞出嚟，還原嗰一個改動都唔會連累其他工作。

第三步：寫日後睇得明嘅訊息

好嘅訊息用一句講清楚改咗乜同點解：

• 好：喺訂單頁面加入 CSV 匯出
• 好：修正預約表格拒絕晚上六點後嘅時間
• 冇用：update、changes、fix stuff

你可以叫 AI 幫你寫：

用一句概括上次 commit 之後嘅改動，以動詞開頭，少於 70 個字元。

第四步：高風險工作用分支

分支即係一條獨立嘅工作線。你可以喺分支度試嘢，如果行唔通，就放棄嗰條分支，主版本一點都唔受影響。

以下情況用分支：

• 改動規模大（重新設計、新付款流程、資料庫改動）。
• 有其他人同時改緊同一個 App。
• 你想喺上線之前俾人審閱改動。

工作完成並測試通過之後，會合併返主分支。喺 GitHub 上，通常係透過**拉取請求（pull request）**完成，即係一個列出所有改動、等待審閱嘅頁面。如果你嘅工具只同步一個分支，開發者就可以喺 GitHub 端管理分支。

第五步：安全咁還原

當 prompt 令 App 壞咗，唔好即刻再連續叫 AI 改五次。返去最後一個正常嘅版本，然後用一個更清晰嘅 prompt 再試。

• **喺建置工具入面：**如果有檢查點或者還原功能，就用嗰個。
• 喺 Git 入面：git revert 會建立一個新 commit 去撤銷舊嘅 commit，歷史紀錄完整保留，對於其他人可能已經 pull 過嘅程式碼嚟講係最安全嘅選擇。
• 避免喺共用分支上用 git push --force，除非你清楚知道原因。佢會改寫所有人嘅歷史紀錄。

如果你唔確定，可以問：

上一次改動令登入頁壞咗。同上一個 commit 比較，告訴我佢改咗邊啲檔案，並解釋每一處改動做咗乜。暫時唔好改任何嘢。

第六步：叫 AI 之前先 pull

如果開發者或者其他工具喺 GitHub 上改咗程式碼，AI 建置工具喺你 pull 嗰啲改動入嚟之前係唔會知道㗎。基於舊嘅程式碼下 prompt，就會引致衝突同遺失工作。

• 每次開始工作時都 pull。
• 講清楚邊個負責改邊啲嘢，避免兩邊同時改同一批檔案。
• 如果出現合併衝突（同一行俾兩邊都改過），就請開發者或者 AI 解決，並解釋點解揀咗嗰個版本。

例子 prompt

開始之前：自我上次工作之後，儲存庫有咩改動？總結一下 commit。

獨立咁做下一個改動：喺每張發票加一個「複製」按鈕。其他嘢唔好改，等我可以另外 commit 呢個改動。

檢查 Git 入面有冇追蹤到任何 API 金鑰、密碼或者 .env 檔案，包括過往嘅 commit。只報告檔案名稱，唔好報告數值。

常見錯誤

• Commit 咗機密資料。 一旦金鑰入咗 Git 歷史，就算你刪除個檔案，佢都已經外洩。要即刻更換。
• 每星期一個超大嘅 commit。 你就冇辦法只撤銷一個改動而唔連累其他嘢。
• 用「update」之類嘅訊息。 歷史紀錄就冇用，搵唔到邊樣嘢搞壞咗。
• 用過時嘅程式碼下 prompt。 其他人正在改嘅時候，先 pull。
• 用 force push 去修正錯誤。 可能會刪走其他人嘅工作。改用 revert。
• Commit 咗 node_modules。 體積好大，而且反正都會由鎖定檔重新生成。

檢查清單

• 專案已連接到一個私人儲存庫。
• .gitignore 排除咗 .env、node_modules、建置輸出同機密資料。
• 每次有效改動之後都 commit。
• Commit 訊息用一句講清楚改咗乜。
• 大型或者高風險嘅改動會開分支，並經過審閱。
• 如果有其他人改緊程式碼，下 prompt 之前先 pull。
• 用檢查點或者 git revert 還原，唔會用 force push。
• 任何曾經被 commit 過嘅金鑰都已經更換。

Mythex 上嘅 Git

Mythex 每次 agent 成功完成一個回合後都會儲存一個 Git 檢查點，而還原到呢個點就會將專案退返去嗰個版本，即係第五步講嘅建置工具端還原。詳情可以睇 Iterate without rebuilding。

喺 Pro 方案，GitHub 同步可以喺專案設定入面連接一個儲存庫，令你同儲存庫之間可以 push 同 pull；匯出就會下載專案，並且排除機密資料同 node_modules。詳情可以睇 GitHub, export, and import。喺交俾開發者之前先連接 GitHub，交接會容易好多，見 點樣同開發者合作處理 AI 建立嘅 App 同 點樣匯出同自行託管 AI 建立嘅 App。

常見問題