給非技術人員的 Github 教學，Vibe Coding 必學的基礎技能

如果你沒有程式背景 最近卻迷上了用 AI 寫程式 也就是所謂的 vibe coding 那你絕對遇過一種狀況 就是 Claude 或者是 Cursor 突然問你 要不要 commit ？

要不要開個分支？

或者是要不要發個 PR ？

這些聽起來像外星文的術語 背後其實全都指向同一個東西 那就是 Git 如果你每天被這些名詞轟炸 卻還是搞不懂它們到底在幹嘛 那麼今天的影片你一定要看完 我會用最白話的方式 搭配實際的案例 帶你一次搞懂 Git 和 GitHub 的概念與用法 同時，我也會告訴你 身為一個用 AI 寫程式的 Vibe Coder 要怎麼把這些工具 無縫融入你的開發流程中

讓你下次看到 AI 吐出這些專有名詞的時候 你就不會再心慌慌不知道自己在幹嘛了 那我們就直接開始今天的主題 假設今天 Gary 心血來潮 想要做一個記帳軟體 於是他打開 Claude Code 請 AI 幫忙 過沒多久 AI 就順利幫他把第一版的畫面給做出來了 但這個時候 Gary 遇到了一個問題 我寫好的這些程式 到底可以放在哪裡呢？

他不想讓程式只能留在這台電腦裡 畢竟他之後可能會想換別台電腦接著寫 或者想把做好的東西分享給朋友看 於是他就想 有沒有一種像 Google Drive 一樣的工具 可以讓我把程式碼直接存在雲端上呢？

這時候 我們就會用到今天的第一個關鍵工具 也就是 GitHub 你可以先簡單把 GitHub 理解成程式碼專用的 Google Drive 工程師們都會把程式碼上傳到 GitHub 讓有權限的人都能夠隨時查看 甚至是一起編輯 但下一個問題就來了 我要怎麼把我電腦裡這些寫好程式的資料夾 上傳到 GitHub 呢？

其實啊 你不能像用 Google Drive 那樣 直接把整個資料夾拖進去就好 你可以想像 我們以前寫報告的時候 資料夾裡常常會出現報告 v1 報告 最終版 報告 打死不改版這種檔案 像這樣留下每次修改歷史的行為 就叫做版本紀錄 因為 GitHub 主要是用來 讓大家協作跟追蹤程式碼進度的 所以它不收單純的檔案 它只接收已經做好版本紀錄的專案 也就是說 在上傳之前

你必須先在自己的電腦裡 幫程式碼建立起這個紀錄系統 而要幫資料夾建立這種版本紀錄的關鍵工具 就是 Git 我們可以想像一下 如果今天沒有 Git 當 Gary 請 AI 幫忙加一個新功能 結果 AI 不小心把原本好好的程式給改壞了 這時候最崩潰的點在於 你根本不知道 AI 剛剛到底動了哪些檔案 也完全不知道該怎麼讓程式 恢復到上一個正常的狀態 但如果有了 Git 那就不一樣了 不管 AI 怎麼亂改

你隨時都有辦法把程式 回溯到之前正常的樣子 所以 在把專案放上 GitHub 之前 Claude Code 通常會先問你 要不要設定 Git 或者是直接幫你跑一行 叫做 git init 的指令 這行指令的意思非常簡單 它就是在跟 Git 這個版本管理工具說 嘿，請你開始幫我追蹤 這個資料夾裡的所有變動 講到這裡，我們先停一下 你只要先分清楚這兩個東西就好 GitHub 是在雲端儲存和管理程式碼的網站 而 Git

則是幫你在本機端管理程式碼版本的工具 回到 Gary 的例子 因為他想把程式放到 GitHub 上 所以他現在的第一步 就是必須先讓他電腦裡的這個資料夾 開始被 Git 給追蹤 設定好 Git 之後 Gary 又繼續寫了一陣子 好不容易終於把登入頁面給做出來了 他看著這個終於能順利運作的程式 心裡想 我好不容易才把登入功能搞定 我想要在這邊先建立一個版本紀錄

這樣萬一之後 AI 又把程式改壞了 我才可以隨時退回到現在這個正常的狀態 當你有這種想要存檔的念頭時 你要知道 這就對應著 Git 裡面的 commit 功能 你可以把 commit 想像成是在玩遊戲的時候 打大魔王之前 你會先手動存檔的那個動作 commit 最大的價值在於 它幫你的程式碼建立了一個絕對安全的檢查點 只要你做了 commit 這份正常的狀態就被永久封存了

接下來就算 AI 發瘋 把你的程式碼全刪了或是改得亂七八糟 你都可以瞬間把程式碼還原回 你當初 commit 的那個完美狀態 所以 當 Claude Code 幫你寫完一段程式 主動問你要不要 commit ？的時候

主動問你要不要 commit ？的時候 它其實就是在問你 現在這個好好的狀態 你要不要先幫它存個檔，買個保險？

這裡有一個觀念一定要特別注意 commit 不是上傳 也不是把東西放到 GitHub 上 commit 只是單純在你自己的電腦裡面 幫目前的狀態留下一份紀錄而已 所以 當你自己覺得這一版跑起來沒問題 想要留個底的時候 你也可以主動跟 AI 說 現在這版測試都沒問題 幫我 commit 一下 並且在訊息裡寫清楚這次修改了什麼 好 現在 Gary 順利為他的登入頁面做了一個 commit 存檔 接著他一定會想

既然我自己電腦裡已經有一個滿意的版本了 我是不是該把它丟到網路上備份 順便準備分享給朋友看呢？

當你有這種想把電腦裡存好的進度 上傳到雲端的念頭時 對應的 Git 動作 就叫做 push 這邊我們要再幫大家強調一次 commit 跟 push 完全是兩回事 commit 只是在你自己的電腦裡面存檔 而 push 才是真的把你電腦裡存好的檔案 推送到雲端的 GitHub 上 不過 在你真的把東西 push 上去之前 有一件事是所有 vibe coder 都要知道的 不然可能會出大事

因為 Gary 的記帳軟體裡面 剛好藏了一把用來串接金流的 API 金鑰 你可以把這種金鑰想像成是你家大門的鑰匙 如果它跟著程式碼一起被 push 到 GitHub 上 就等於是你把鑰匙公開貼在網路上 任何人都可以撿去用 甚至拿去盜刷你的信用卡帳號 前面提到的情況 就算 AI 把程式改壞了都還有救 但金鑰一旦外洩流傳出去 那就真的救不回來了 只能整把作廢重新申請

就像信用卡被盜刷後只能掛失原本的卡片 重新補發一張 所以在 push 之前 我們會需要用到一個叫做 git ignore 的檔案 它的作用非常單純 就是用來告訴 Git 這些特定的檔案請不要追蹤 也絕對不要上傳 而且你根本不用自己去記哪些檔案該擋 只要直接跟 Claude Code 說 幫我確認 env 檔 密碼還有各種金鑰或者機密檔案 都已經放進 gitignore 裡面 絕對不要 commit 上去 這樣就可以了 第一次做 push 的時候

你可能會看到 AI 跑出一些看起來很長的指令 像是設定 remote 啦 或者是 push 到 origin main 啦 其實你完全不用被這些字眼給嚇到 remote 顧名思義就是遠端的地址 跟它相對應的叫做 local 也就是你電腦本地的資料夾 而 origin 通常就是指你在 GitHub 上的那個專案資料夾 至於 main 則代表這個專案目前的官方正式版 所以 push 到 origin main 翻譯成白話文就是

請幫我把現在寫好的這個正式版本 傳送到雲端的那個專案資料夾裡面 順利上傳之後 Gary 很開心地把 GitHub 的連結丟給他的朋友 朋友收到連結之後就會想 那我要怎麼把這個專案 抓到我自己的電腦裡呢？

而且我不只想要拿到現在的檔案 如果之後我修改了程式 我也想把它上傳回 Gary 的 GitHub 裡面 這樣我們就可以一起維護這套程式 當朋友有這種想一起共同編輯這個專案的念頭時 他需要的動作 就叫做 clone 這裡也要特別注意喔！

clone 跟你在 GitHub 網頁上 常看到的另一個選項 Download ZIP 是完全不一樣的東西 如果你只是按 Download ZIP 那你抓下來的 就只是一包純粹的檔案 裡面完全沒有被 Git 追蹤的紀錄 這樣一來 如果 Gary 的朋友之後改了程式碼 他是沒辦法把改動同步回 GitHub 上的 但如果是用 clone 把專案抓下來 那就等於是你正式加入了這個專案 只要 Gary 有在 GitHub 上 把你加入成協作者 之後你做了任何修改

想要上傳回去都會非常輕鬆 過沒多久 Gary 的朋友幫忙增加了一個新的功能 Gary 這時候就想 朋友剛剛已經把新寫好的東西推送到雲端了 那我自己的電腦 要怎麼拿到他最新改好的版本呢？

這邊對應的 Git 指令 就叫做 pull 它會去把 GitHub 上面最新版本的程式碼給抓下來 並且同步到 Gary 自己的電腦裡 所以 如果以後你要跟朋友一起用 AI 寫程式 你們合作的基礎循環就會是這個樣子 第一次加入專案要把程式碼抓下來 叫做 clone 平常想同步別人的最新進度 叫做 pull 自己改好東西想要存檔 先用 commit 最後想把自己的進度送上雲端 就用 push

把這個合作循環建立起來之後 接下來 Gary 準備要來開發一個大功能了 他這次想要幫記帳軟體加上資料庫的功能 這樣就能儲存用戶的資料 但是 他不想要直接在目前的穩定版本 也就是我們剛剛提到的 main 上面 去開發這個新功能 因為 Gary 是 Vibe Coder 他很怕把自己辛辛苦苦的東西改爆了 這時候就要引進 Git 裡面 另一個非常關鍵的概念

也就是分支 英文叫做 branch 在 Git 的世界裡 所有的專案一開始都會有一條主線 叫做 main 這條線代表的是穩定運行中的程式碼 我們之所以要開 branch 目的其實非常單純 就是要讓正在開發中 還不穩定的功能 跟已經寫好 很穩定的功能徹底分開 讓它們井水不犯河水 這時候你可能會想 既然我前面已經學會用 commit 來存檔了

那我直接讓 AI 在 main 主線上面改 如果它改壞了 我再退回到上一個 commit 不就好了嗎？

為什麼大家都一定要叫我開 一個叫做 branch 的東西呢？

其實原因很簡單 因為當 AI 在幫你寫比較複雜的大功能時 它通常不會一次就寫對 而是會需要反覆試錯 修改好幾次 如果你一直都在 main 上面讓它改 那在 AI 試錯的這段期間 你的程式就會一直處於一種半壞掉的狀態 這時候如果朋友突然想看看你的記帳軟體 或者是你突然發現畫面上有一處拼字錯誤 需要緊急修正 你就會非常尷尬

因為你這條作為專案門面的 main 現在根本就跑不動 你可以把你的專案資料夾 想像成一張神奇辦公桌 而 Branch 就像是這張桌子旁邊的平行時空切換按鈕 當你按下 main 桌上會呈現穩定版本的程式碼 當你按下新功能 branch 桌上的東西會瞬間變成你正在開發中的草稿 也就是說 Branch 讓你可以隨時在同一張辦公桌上 安全地把不同任務的進度切換來 切換去

不用擔心弄亂原本的東西 如果這個新功能的草稿真的被 AI 改爛了 最壞的狀況就是把這個 branch 直接刪掉 然後切回 main 而你的 main 依然毫髮無傷 所以你可以這樣記 當你準備要開發一個新功能的時候 第一步就是請 AI 開一個 branch 然後接下來所有的程式改動 都在這個 branch 上面做 commit 在這個時代 我不會說你必須要學會 git 指令 但你一定要知道這些名詞 功能是幹嘛的

這樣你就可以直接跟 AI 說 嘿，先幫我從 main 開一條新的 branch 專門用來做這次的資料庫功能 之後所有的改動都幫我 commit 在這條 branch 上 絕對不要動到 main 不過現在情況又變了 Gary 在等 Claude Code 開發資料庫功能的同時 他又想要開另一個 Claude Code 來幫他重新設計 UI 畫面 但如果你直接叫 AI 同時在同一個資料夾裡 做這兩件事 那絕對會是一場災難 為什麼呢？

回到剛剛神奇辦公桌的比喻 Branch 的致命傷在於 雖然你可以切換不同狀態 但你終究只有一張辦公桌 也就是說 這張桌子同一個時間只能顯示一個平行時空 如果你硬要叫兩個 AI 同時在這唯一的一張桌子上做事 一個要看資料庫藍圖 一個要看 UI 設計稿 它們就會為了搶這張桌子的顯示狀態 而大打出手 你明明在開發資料庫的 branch 上

裡面卻混進了修改 UI 的 commit 這會讓整個 Git 的狀態變得非常混亂 為了解決這個問題 我們就需要認識 worktree 這個超好用的功能 既然一張桌子不夠用 最暴力的解決辦法是什麼？

就是直接去 IKEA 再買第二張實體的辦公桌放在旁邊！

你可以這樣想 Branch 像是在同一張桌子上切換不同的時空 同一個時間你只能看見一個畫面 而 Worktree 則是直接給你第二張實體的桌子 讓兩個時空可以同時並存在你的電腦裡 所以當你跟 Claude Code 說 你要開一個新的 worktree 時 它其實就是在你電腦裡 生出一個全新的實體資料夾 也就是這第二張桌子 所以 如果 Gary 想同時開發資料庫又想修改 UI 他就可以請 AI 開兩個 worktree

這時候 AI 就會生出兩個獨立的資料夾 最棒的是 這兩張桌子是連通同一個 Git 記憶庫的！

所以你可以讓 Agent A 去第一張桌子 負責資料庫的 branch 讓 Agent B 去第二張桌子 負責 UI 的 branch 這樣一來 這兩個 AI 就像是擁有了各自專屬的實體辦公桌 能在各自的資料夾裡各司其職 平行開發的效率直接拉滿 完全不會互相干擾 以前的工程師其實不太會用到 worktree 畢竟一個人沒有三頭六臂 一次大概也就是專心做一件事 但是現在時代不一樣了 身為一個 Vibe Coder

你真的很有可能會同時開兩三個 AI Agent 讓它們平行工作 而不是呆呆地排隊等一個做完才換下一個 這時候 你就一定會需要用到 worktree 過了一陣子 Gary 讓好幾個 AI 在各自的工作區裡 順利把自己負責的新功能都寫完了 這時候 他想要把這條 branch 上做好的功能 在正式合併進 main 之前 先丟給朋友 review 檢查一下 這個動作 在 GitHub 上就叫做開 PR

PR 的全名叫做 Pull Request 你可以先把它想像成是一份改動提案 當你開好 PR 之後 這份提案就會被送到 GitHub 上 讓大家一起來審核這次的改動合不合理 而且 開 PR 這件事你也不用自己動手 可以直接請 AI 代勞 只要跟你的 agent 說 幫我把這條 branch 開一個 PR 內容說明一下這次做了什麼功能 改了哪些檔案 還有要怎麼去測試它 AI 就會幫你把這份提案整理得清清楚楚

讓幫你 review 的人一看就懂 當大家都檢查過 覺得 Gary 這次的改動完全沒有問題之後 最後一個動作 就是要將這次的程式碼變動 正式合併回主線 main 裡面 這個合併的動作 對應的 Git 指令就叫做 merge 當大家在 GitHub 網頁上按下 Merge 按鈕之後 雲端上的 main 就正式更新了 這邊要提醒一個新手最容易誤會的地方 因為這個合併是在雲端網頁上發生的 所以你自己電腦本機裡的 main

並不會自動通靈跟著變 很多人會有一種錯覺 以為我在 VS Code 或者是 Cursor 裡面 看到的程式碼 就是 GitHub 上最新的版本 其實並不是 你看到的永遠都是你電腦本機目前的狀態 雲端更新了 你的電腦是不會通靈自動去同步的 所以 每次只要有新功能被合併進 main 之後 一定要記得切回本機的 main 並且叫你的 agent 再執行一次 pull 手動把雲端最新的版本給拉下來 這樣一來

你下次開新的 branch 時 才是從最新的進度出發 而不會一直活在一個過時的舊版本裡 不過 在合併程式碼的過程中 有時候會遇到另一種讓人頭痛的狀況 那就是 conflict 也就是所謂的衝突 假設 Gary 跟朋友剛好都改到了 同一個檔案的同一個地方 或者是兩個 AI Agent 剛好去動到了 同一段核心邏輯 這時候 Git 就會跳出 conflict 的警告 conflict 的意思很直白

就是 Git 發現同一段程式碼內容 現在竟然出現了兩個完全不同的版本 它不知道該聽誰的 在現在 AI Coding 的時代 像 Claude Code 這種工具 遇到 conflict 時是會自己去判斷跟處理的 那它是怎麼處理的呢？

當 Git 發現衝突時 它會在檔案裡留下一些特殊的標記 把兩邊打架的程式碼上下並列出來 AI 看到這些標記之後 會先去分析這兩個版本各自到底想做什麼 然後通常會用以下這三種方式來幫你合併 第一種方式是二選一 如果 AI 判斷出朋友改的那一版才是最新的邏輯 或者是你原本的寫法有個 Bug 剛好被朋友給修好了 它就會直接捨棄舊的寫法 只保留正確的那一邊 第二種方式是兩邊都留 你可能會想

既然兩邊不衝突 Git 怎麼還會跳警告呢？

這是因為有時候你們剛好改到了同一行程式 Git 比較死板 只要看到同一行被兩個人動過 它就會判定為衝突 比如 Gary 在清單的最後一行加了理財分類 而朋友也在最後一行加了日常分類 Git 嚇死了以為這就是衝突 但 AI 看得懂這其實只是在新增不同的項目 它就會很聰明地幫你解開這個衝突 把兩個項目都保留下來 湊進同一個選單裡 皆大歡喜 至於第三種就比較特別了 叫做打掉重練幫你改寫

很多時候 兩個人改的邏輯如果硬生生拼在一起 程式很可能會直接出錯 這時候 AI 在看懂你們雙方的目的之後 會乾脆把那一段程式碼重寫一遍 用新的寫法把兩邊的功能順順地接在一起 雖然 AI 有這幾種聰明的合併方法 但它終究不知道你的產品規劃是什麼 如果 Gary 跟朋友改的邏輯 在產品邏輯上是互相衝突的 AI 就會卡住 不知道該選哪一種方法 所以這時候 身為一個 Vibe Coder

你要做的不是自己下去改程式 而是要給出明確的產品決策 你只要跟 AI 說 幫我解掉這個 conflict 分類列表的邏輯以朋友的為主 但是把我的『理財分類』 移到右邊的進階選單裡面 只要你把取捨的方向跟規則講清楚 AI 就會自己挑選最適合的合併方式 幫你把衝突的程式碼完美地接合起來 最後 我們來聊聊 Vibe Coder 每天都在怕的時刻 那就是

如果 AI 把程式碼改壞了 到底該怎麼救？

這裡我們分成兩種最常見的情境來討論 第一種情境是 你還沒 commit AI 剛剛幫你改了一大堆檔案 你跑了一下發現完全不對 但好險你還沒有把它們存成 commit 當你有我確定不要這批改動了 我要回到上一次正常狀態的念頭時 對應的動作叫做 restore 白話一點說 它就是讓你一鍵讀檔 回到上一次的遊戲存檔點 就當作剛剛 AI 亂寫的事情完全沒發生過 第二種情境是

你已經 commit 了 你順手存檔之後 跑了一下程式 才驚覺剛剛那次 commit 根本是錯的 這時候 比較安全的補救做法通常是 revert 要注意喔 revert 不是偷偷把你的歷史紀錄給刪掉 它是去新增一個反向的 commit 去把前面那次錯誤的改動給抵消掉 這個做法在跟朋友合作專案的時候特別安全 因為所有人都能在歷史紀錄裡 看到有加錯東西

然後又被抵消掉的完整過程 而不會覺得某一段進度怎麼突然憑空消失了 最棒的是 這些指令你其實都不用自己硬背 當你發現 AI 改壞的時候 你只要直接跟它說 剛剛這次的改動我不要了 請幫我回到上一個正常的版本 AI 自己就會去判斷現在的狀態 決定該用 restore 還是 revert 來幫你處理 好 到了這裡 我們來總結一下今天 Gary 學到了什麼？

他現在知道了 寫好的程式可以備份到 GitHub 這個雲端倉庫上 而在上傳之前 必須先設定好 Git 來做本機端的版本管理 當 AI 提到 commit 的時候 他明白這是在幫程式當下的狀態 留一個存檔快照 當準備要 push 的時候 就是在把電腦裡的存檔 正式推送到雲端 如果有朋友想加入開發 就請他用 clone 把專案抓下來 如果朋友上傳了新進度 就用 pull 把最新的版本拉回自己的電腦裡

當 AI 準備要大改功能的時候 他會要求開一條 branch 當作安全的實驗沙盒 如果想同時讓好幾個 AI 幫忙做不同的事情 他就會利用 worktree 讓每條 branch 都能擁有自己的實體資料夾 等所有的功能都寫完測試過後 再透過開 PR 和 merge 把成果正式收回到 main 主線 萬一合併時遇到 conflict 衝突 他也知道這不是世界末日 這只是 Git 在等他下達明確的產品決策

而就算 AI 真的把程式改到無法挽救 只要還沒 commit 就可以用 restore 一鍵復原 如果不小心 commit 了 也可以用 revert 安全地把錯誤給抵消掉 所以你看 或許對你來說 Git 是一堆難背的火星文指令 但你只要有能力指揮就可以了 只要你能把這些概念 對應到它可以幫你解決開發上的什麼問題 一切也會變得非常好理解 你不需要在今天就逼自己變成 Git 專家 但你要知道

當 Claude 或者是 Cursor 問你 要不要 commit ？

要不要開 branch ？

要不要發 PR 的時候 它其實是在問你 這次的開發你要不要先存檔？

你要不要開個空間來隔離風險？

你要不要把寫好的東西交出去給別人檢查？

只要這些判斷你聽得懂 你用 AI 開發就會踏實很多 今天這集，我盡量把 Git 最核心的幾個情境 用最白話的方式講清楚 不過實際開發時遇到的狀況 其實不只這些 所以我把日常最常見的 27 個情境 整理成了一份更完整的對照表 每一種狀況，都直接對應到該用的 Git 指令 還有給 AI 的提示詞範例 如果你手邊已經有在開發的專案 我也附了一組提示詞 幫你檢查它現在的 Git 健康度 如果這些對你有幫助

可以來我的 Patreon 看看 連結我放在資訊欄 那以上就是今天的內容 各位喜歡的話記得幫我按讚 追蹤加分享 這是我持續創作下去的動力 我們下次見！