Gary Talks Stuff：Git 與 GitHub

開場閒聊

Gary 從 Vibe Coding 新手最容易慌張的畫面開始：Claude 或 Cursor 突然問「要不要 commit？要不要開 branch？要不要發 PR？」對沒有程式背景的人來說，這些字眼像外星文一樣，但它們其實都在描述同一件事——如何安全地管理 AI 寫出來的程式。

影片用製作記帳軟體作為主線，把 Git 與 GitHub 放進一個連續的開發情境裡。重點不是要求觀眾背熟所有指令，而是先理解每個動作在解決什麼問題，之後才能放心把工作交給 AI Agent。

懶人包速覽

核心痛點	解決方案／關鍵觀點
程式只留在本機，換電腦或分享不方便	GitHub 是雲端上的程式碼倉庫，Git 負責本機版本管理
AI 改壞程式，不知道怎麼回復	用 commit 建立安全存檔；尚未提交可用 restore，已提交可用 revert
新功能開發會弄壞穩定版本	從 main 開 branch，把實驗性修改隔離出去
多個 AI Agent 同時工作會互相干擾	用 worktree 建立多個實體資料夾，讓不同 branch 平行開發

主編開場：Vibe Coder 不必背指令，但要懂風險

我推薦這支影片給正在使用 Claude、Cursor 或其他 AI coding 工具的人，因為它沒有從複雜指令出發，而是先處理「AI 為什麼一直叫我做這些事」的疑惑。只要掌握版本保存、同步、隔離與審核四個概念，就能把 AI 的提示轉換成可控的開發流程。

這種理解也很重要：AI 可以代為執行指令，卻不應該替使用者決定哪些成果值得保存、哪些改動可以合併。人要掌握的是開發狀態與產品取捨，工具才有安全運作的邊界。

Git 與 GitHub：本機版本管理與雲端協作

影片先用「程式碼專用的 Google Drive」來比喻 GitHub。GitHub 讓程式碼存放在雲端，也讓有權限的人查看與共同編輯；但它不是單純把資料夾拖上去的檔案空間，而是建立在版本記錄與協作流程之上。

Git 則是在本機端追蹤資料夾變化的工具。當 Cursor 執行 git init，意思是請 Git 開始記錄這個專案的變動。兩者的分工要先記清楚：Git 管本機的版本歷史，GitHub 管雲端的程式碼與協作。

如果沒有 Git，AI 加功能時不小心改壞原本的程式，使用者很難知道哪些檔案被動過，也不容易回到上一個正常狀態。有了版本記錄，後續的每一次修改都能被放在歷史脈絡裡處理。

commit 與 push：存檔不等於上傳

當記帳軟體的登入頁面完成，Gary 想把這個正常狀態留下來，對應的 Git 動作就是 commit。影片把 commit 比喻成遊戲打大魔王前的手動存檔：它建立一個安全的檢查點，之後即使 AI 把程式改得一團亂，也有機會回到這個狀態。

commit 只發生在自己的電腦上，不代表程式已經上傳到 GitHub。當使用者想把本機已保存的進度推送到雲端，才會用到 push。因此，看到 AI 問要不要 commit，可以理解成「目前這個狀態要不要先存檔」；看到 push，則是「要不要把本機的存檔送到遠端」。

影片也提醒，commit 訊息最好清楚說明這次修改了什麼。這樣日後查找歷史記錄時，不必重新猜測某個版本的內容與目的。

API 金鑰與 Git ignore：上傳前的安全閘門

在 push 之前，Vibe Coder 必須特別注意機密資訊。記帳軟體可能含有金流 API 金鑰，這類金鑰就像家門鑰匙；一旦跟著程式碼進入公開的 GitHub，可能被拿去濫用，事後不能只靠回復程式碼來挽救。

影片介紹 .gitignore 的作用：告訴 Git 哪些檔案不要追蹤，也不要 commit 或上傳。常見需要排除的內容包括 .env、密碼、API 金鑰與其他機密檔案。對不熟悉規則的使用者，可以讓 AI 協助檢查這些檔案是否已被加入 ignore 清單，但仍要自己確認結果。

這裡的關鍵不是記住某個檔名，而是建立上傳前的檢查習慣。程式改壞還有版本工具可以處理，秘密一旦外洩，通常必須立刻撤銷並重新申請。

clone、pull、remote 與 origin：協作的同步循環

朋友要加入 Gary 的專案時，影片區分了 clone 與 GitHub 網頁上的 Download ZIP。Download ZIP 只會取得一包檔案，不包含 Git 的追蹤記錄；clone 則會把專案與版本脈絡一起帶到本機，方便後續繼續修改與同步。

朋友把新功能 push 到 GitHub 後，Gary 要把最新進度帶回自己的電腦，就使用 pull。因此，協作的基本循環可以整理成：第一次加入專案用 clone，平常取得他人最新進度用 pull，自己的修改先 commit，再用 push 送到雲端。

影片也解釋常見的 remote、local、origin 與 main。remote 是遠端地址，local 是本機資料夾，origin 通常指向 GitHub 上的專案，而 main 通常代表目前的正式主線。看到 push to origin main，可以把它理解成把本機的正式版本送到 GitHub 專案的 main。

branch：把不穩定功能隔離開來

當 Gary 要替記帳軟體加入資料庫功能時，他不希望直接在穩定的 main 上修改，因此需要建立 branch。main 可以視為穩定運作中的主線，branch 則是從主線分出去的開發空間。

只在 main 上開發的問題是，AI 可能需要反覆試錯，讓專案在一段時間內處於半完成或半損壞的狀態。此時若要展示原本能運作的版本，或緊急修正其他問題，就會受到正在開發中的修改干擾。

branch 的價值就是隔離風險。新功能可以在自己的 branch 上持續 commit，若 AI 把它改壞，最壞的情況是刪除這條 branch，再切回仍然完整的 main。對 Vibe Coder 而言，與其背下大量指令，不如能清楚告訴 AI：「從 main 開一條 branch，這次所有資料庫功能都只在這條 branch 上處理。」

worktree：讓多個 AI Agent 擁有自己的工作區

單一 branch 可以隔離版本狀態，但一個資料夾同一時間通常只能呈現一個 branch 的內容。如果同時讓兩個 AI Agent 在同一個資料夾工作，一個修改資料庫、一個重新設計 UI，就可能把不同任務的修改混在一起。

影片用辦公桌比喻兩者差異：branch 像在同一張桌子上切換平行時空，而 worktree 則像多買一張實體辦公桌。建立 worktree 後，Git 可以讓不同 branch 各自擁有獨立的實體資料夾，同時共享同一個 Git 記憶庫。

這讓 Agent A 可以在一個 worktree 處理資料庫，Agent B 在另一個 worktree 處理 UI。對一次只做一件事的人來說，worktree 可能不是日常必需品；但當 Vibe Coder 同時啟動兩三個 AI Agent，平行工作區就能降低互相覆蓋與混入錯誤 commit 的風險。

PR 與 merge：先審核，再回到正式主線

功能在 branch 上完成並測試後，不必立刻合併到 main。可以先在 GitHub 開一個 PR，也就是 Pull Request，把 branch 的修改當成一份改動提案，交給自己或協作者檢查。

PR 內容可以由 AI 協助整理，包括這次完成了什麼功能、修改了哪些檔案，以及要如何測試。這種說明讓 review 不只是看程式碼差異，也能理解改動的目標與驗證方式。

大家確認功能沒有問題後，才在 GitHub 上按下 merge，把 branch 的成果合併回雲端的 main。要注意，雲端 main 更新不代表本機 main 會自動同步；合併完成後，使用者仍要切回本機 main，執行 pull 取得最新版本，再從新的進度開下一條 branch。

conflict：AI 可以協助，但產品取捨要由人決定

當兩個人或兩個 AI Agent 修改同一個檔案的同一段邏輯，Git 可能產生 conflict。這表示同一份程式碼出現兩個不同版本，Git 無法單純判斷應該保留哪一邊。

影片提到，AI 通常會先分析雙方的意圖，再採取三種處理方向：選擇其中一邊、把兩邊不衝突的內容都留下，或重新改寫一段邏輯，將兩項功能接在一起。

但如果兩邊的產品邏輯真的互相矛盾，AI 不知道哪個取捨才符合產品規劃。此時 Vibe Coder 的責任不是盲目接受自動合併，而是清楚告訴 AI決策規則，例如以朋友版本的分類邏輯為主，再把自己的理財分類移到進階選單。人負責定義方向，AI 才能依規則完成技術上的整合。

restore 與 revert：改壞程式時的兩種救援方式

影片最後整理兩種常見的復原情境。第一種是 AI 已經改了很多檔案，但使用者尚未 commit。這時可以使用 restore，放棄目前未提交的修改，回到上一個正常狀態。

第二種是錯誤修改已經被 commit。此時較安全的做法通常是 revert，新增一個反向 commit，把先前的錯誤變更抵銷。revert 不會偷偷刪除歷史紀錄，合作團隊仍然看得到原本的變更以及後續的修正過程。

這個區分很實用：尚未存檔的錯誤，重點是丟掉目前工作區變更；已經存檔的錯誤，則用新的歷史記錄抵銷舊變更。使用者可以直接向 AI 描述「這次修改不要了，回到上一個正常版本」，再請 AI 根據目前狀態判斷應使用 restore 或 revert。

QA 精選

Q1：GitHub 和 Git 到底有什麼不同？

GitHub 是雲端上的程式碼倉庫與協作平台，讓程式碼可以被保存、分享與共同維護；Git 是本機端的版本管理工具，負責追蹤資料夾的修改歷史。通常要先用 Git 建立版本記錄，才方便將成果推送到 GitHub。

Q2：commit 和 push 的差別是什麼？

commit 是在自己的電腦上替目前程式狀態建立快照，push 則是把已經 commit 的本機進度送到 GitHub。commit 不等於上傳，只有 push 才會更新遠端專案。

Q3：為什麼不能直接在 main 上開發新功能？

AI 開發複雜功能時可能反覆試錯，若直接修改 main，穩定版本會在開發期間被半成品干擾。建立 branch 可以把新功能放進獨立的實驗空間，完成測試後再透過 PR 與 merge 回到 main。

Q4：branch 和 worktree 的差別在哪裡？

branch 是版本上的分支，主要用來隔離不同開發方向；worktree 則是為 branch 建立獨立的實體資料夾。單一資料夾同一時間通常只呈現一個 branch，而多個 worktree 能讓不同 AI Agent 同時在不同資料夾平行工作。

Q5：Download ZIP 可以取代 clone 嗎？

如果只是想拿到一份檔案，Download ZIP 可以做到；但它不包含 Git 的版本追蹤記錄，後續修改不容易同步回 GitHub。要正式加入協作，應使用 clone，才能保留完整的 Git 脈絡。

Q6：遇到 conflict 時，AI 可以完全替我決定嗎？

AI 可以分析兩邊修改的內容，協助選擇一邊、保留兩邊或重新整理程式碼，但若衝突涉及產品規則，仍需要人說明取捨方向。清楚的產品決策，才是 AI 能正確解 conflict 的前提。

Q7：restore 和 revert 分別適用於什麼時候？

尚未 commit 的錯誤修改，可以用 restore 放棄工作區變更；已經 commit 的錯誤，則可用 revert 新增一個反向 commit 來抵銷。後者會保留完整歷史，較適合協作中的專案。

主編隨筆

這支影片最值得保留的不是一串指令，而是一套面對 AI 開發的風險分層。commit 是小型存檔，branch 是功能隔離，worktree 是多人或多 Agent 的空間隔離，PR 則是進入正式版本前的審核關卡。把這幾層分開，AI 就不會變成一個只能「希望它不要弄壞」的黑盒子。

對剛開始 Vibe Coding 的人來說，我會建議先建立一個簡單規則：任何較大的功能都不要直接碰 main；每次確認能運作就 commit；要交給別人看就先開 PR；涉及 API 金鑰時，先檢查 .gitignore。這些習慣比背誦指令更能降低成本。尤其當多個 Agent 同時工作時，worktree 與明確的產品決策會變得更加重要，因為並行速度越快，沒有邊界時混亂也會放大得越快。

結語

Git 與 GitHub 的術語看起來很多，但它們其實對應幾個清楚的開發問題：GitHub 負責雲端保存，Git 負責本機版本；commit 是存檔，push 是上傳；clone 與 pull 負責取得協作進度；branch 與 worktree 負責隔離工作；PR 與 merge 負責審核與整合。

當 AI 改壞程式時，尚未 commit 可以 restore，已經 commit 則可以 revert。Vibe Coder 不必立刻成為 Git 專家，但至少要能理解 AI 提出的每個動作是在保存成果、隔離風險、同步版本，還是請別人檢查。掌握這些判斷，就能更踏實地讓 AI 參與開發。