你的隨身碟傳到第幾版了？

在還沒有使用 Git 與 GitHub 的時代，大學生分組做報告、或是公司裡面的小團隊一起寫專案，通常是這樣運作的：

A 同學把寫好的 報告_v1.docx 用 Line 傳給 B 同學。 B 同學下載後，加了兩段話，改名為 報告_v2_B修改.docx 傳到群組。 C 同學同時也在改 報告_v1.docx，他改名為 報告_v2_C補充.docx 也傳到群組。最後組長 A 同學看著桌面上十幾個檔案（包含 報告_最終版_真的不改了.docx），崩潰地打開兩個視窗，用肉眼一行一行對比，把大家的修改複製貼上到同一個檔案裡。

這種被稱為「隨身碟/Line 傳檔法」的協作模式，在寫程式的領域是絕對行不通的。程式碼錯一個標點符號就會整機癱瘓，你不可能用肉眼去對比幾千行的程式碼。

這也是為什麼全世界的軟體公司，都強制要求工程師必須使用 GitHub 作為多人協作的唯一平台。

協作的核心概念：遠端倉庫 (Remote) 與本機 (Local)

在 GitHub 的世界裡，我們把存放在 GitHub 網站上的那個專案資料夾，稱為 「遠端倉庫 (Remote Repository)」，通常預設的名字叫做 origin。而你下載到自己筆電裡面的資料夾，稱為 「本機倉庫 (Local Repository)」。

多人協作的黃金法則只有一條： 「在你要把自己寫好的程式碼推上去 (Push) 之前，永遠、永遠、永遠要先把你同事寫好的程式碼拉下來 (Pull)！」

指令實戰：Pull 與 Push 的日常雙人舞

假設你跟同事「小明」正在一起開發一個 Vibe Tutor 的網站。這個專案已經放在 GitHub 上了。

情境一：你早上剛進辦公室 你第一件要做的事情，不是開始寫程式。而是打開 Cursor 的終端機，輸入： git pull origin main 這行指令的意思是：「請去 GitHub (origin) 的 main 分支，把小明昨晚加班寫的最新程式碼，全部拉下來更新到我的電腦裡。」

情境二：你寫好了一個新功能，準備下班 你完成了「登入功能」，這時候你要把你的心血傳回 GitHub：

git add . (把所有修改加入暫存區)
git commit -m "完成會員登入功能" (寫下修改日記)
git push origin main (把日記跟程式碼推送到 GitHub)

只要你們兩個人都乖乖遵守「先 Pull，再改扣，最後 Push」的循環，你們就可以完美地一起蓋出一座軟體城堡，而且永遠不會把對方的檔案覆蓋掉。

為什麼會發生衝突 (Conflict)？

在一個完美的烏托邦裡，你跟小明永遠在改不同的檔案。你在寫 login.js，他在寫 cart.js，井水不犯河水。

但現實往往是殘酷的。星期二下午，你跟小明「同時」打開了 index.html (首頁)。你在首頁的第 10 行，加了一個「立刻購買」的紅色按鈕。小明在首頁的第 10 行，加了一個「加入購物車」的藍色按鈕。

小明手腳比較快，下午 3 點先 git push 上去了。GitHub 完美接收了小明的藍色按鈕。下午 4 點，你滿心歡喜地輸入 git push，準備下班。

這時候，終端機會噴出一堆紅字： ! [rejected] main -> main (fetch first) hint: Updates were rejected because the remote contains work that you do not have locally.

這句紅字的白話文是：「GitHub 拒絕了你的上傳！因為 GitHub 上面有小明寫的新東西（藍色按鈕），但你的電腦裡沒有。你必須先 pull 下來！」

於是你乖乖聽話，輸入了 git pull。接著，更大的災難發生了，終端機再次噴出刺眼的紅字： CONFLICT (content): Merge conflict in index.html

直球對決！解決衝突 (Merge Conflict) 的 Vibe 心法

遇到衝突時，新手的第一個反應通常是：心跳加速、手心冒汗、甚至想要把整個資料夾刪掉重抓。請深呼吸，告訴自己：「發生衝突是工程師的日常，這是 Git 為了保護我們不互相覆蓋檔案的安全機制。」

當 Git 發現你跟小明改了「同一份檔案的同一行」時，它不知道誰才是對的，所以它把這個決定權交給你。

步驟一：打開發生衝突的檔案

在 Cursor 中打開那個名為 index.html 的檔案。你會看到裡面出現了外星人留下的記號：

<<<<<<< HEAD
<button class="bg-red-500">立刻購買</button>
=======
<button class="bg-blue-500">加入購物車</button>
>>>>>>> 1a2b3c4d... (小明的 commit)

<<<<<<< HEAD 到 ======= 之間：是你自己電腦裡寫的程式碼 (紅色按鈕)。
======= 到 >>>>>>> 之間：是小明從 GitHub 傳下來的程式碼 (藍色按鈕)。

步驟二：呼叫 AI 幫你做決策

在以前，工程師必須用手動刪除那些 <<< 記號，如果不小心多刪了一個括號，程式就壞了。但在 Vibe Coding 時代，你可以直接把這一段「車禍現場」選起來，按 Cmd+K (或 Ctrl+K)，輸入這個 Prompt：

【解決 Git 衝突 Prompt】 「這裡發生了 Git 合併衝突。上面是我寫的紅色購買按鈕，下面是同事寫的藍色購物車按鈕。請幫我把這兩個按鈕『都保留下來』，並排放在一個 div 容器裡面，按鈕之間留一點空隙。」

AI 會瞬間幫你把外星記號清掉，並完美融合你與小明的程式碼：

<div class="flex gap-4">
  <button class="bg-red-500">立刻購買</button>
  <button class="bg-blue-500">加入購物車</button>
</div>

步驟三：標記為已解決並上傳

當你確認程式碼已經修復完成後，回到終端機，告訴 Git 你已經把車禍現場清理乾淨了：

git add index.html (告訴 Git 這個檔案的衝突已經解決)
git commit -m "解決與小明的 index.html 按鈕衝突"
git push origin main

恭喜你！你剛剛成功拆除了一顆足以毀滅新手工程師信心的核彈。掌握了 Pull、Push 與 解決衝突 這三大絕招，你已經具備了進入頂尖軟體公司，與幾十位資深工程師協同作戰的基本門票了！

在下一章中，我們將學習如何利用 GitHub 這個平台，為你自己打造一份閃閃發光的工程師專屬履歷表。