程式碼的副本：git 分支

我們公司用 git 管理所有的程式碼。每次跟客戶或新進同事解釋「分支」這個概念時，對方通常會露出一臉困惑的表情。這篇文章試著用生活中的例子把它說清楚。

先想像一份 Word 文件

你正在寫一份企劃書，已經寫到第三版，老闆也看過了，大致沒問題。這時候你想試一個大膽的新方向——把整份企劃的架構打掉重練。

你會怎麼做？

大部分人會「另存新檔」，取名叫「企劃書_v3_新方向.docx」。這樣原本那份穩定的第三版還在，你可以放心在新檔案裡大改特改。改完覺得不錯，就把新版本的內容搬回正式版；改完覺得不行，直接刪掉新檔案，原本的第三版毫髮無傷。

git 分支做的事情，跟「另存新檔」幾乎一模一樣。只是它更聰明一點。

分支就是「另存新檔」的進化版

在 git 的世界裡，「正式版」叫做 main 分支。它是目前確定沒問題的版本，已經上線、客戶看得到的那一份。

當工程師要修改東西——不管是加新功能、改 bug、還是換一張圖片——他不會直接動 main。他會開一個新的分支，像是「另存新檔」一樣，在副本上做修改。

為什麼不直接改正式版？因為改壞了很麻煩。網站掛掉、功能出錯、客戶看到半成品——這些都是直接在正式版上動刀的風險。

跟「另存新檔」不一樣的地方

Word 的「另存新檔」會複製整份文件，佔兩倍的空間。但 git 分支不會。它只記錄「從這個時間點開始，你做了哪些改動」，所以不管你開十個分支還是一百個分支，都不會讓專案變得很肥。

另一個差異是合併。Word 文件如果有兩個人各自改了不同段落，你得手動比對，一段一段複製貼上。git 可以自動幫你合併——它知道你改了第三段，同事改了第五段，兩個人的修改不衝突，一鍵就能整合回正式版。

當然，如果兩個人剛好改了同一段，git 也會舉手說「我不確定要用哪一版，你們自己決定」。這叫做「衝突」，工程師需要手動處理。但至少 git 會明確告訴你衝突在哪裡，不會默默覆蓋別人的修改。

用餐廳廚房來比喻

如果覺得 Word 的例子還是太抽象，換一個場景。

想像你經營一家餐廳。菜單上有一道招牌紅燒牛肉麵，客人很喜歡，每天穩定出餐。這就是你的 main 分支——正在營運的版本。

某天你想試試看加花椒會不會更好吃。你不會直接改掉廚房裡的標準食譜，因為萬一客人覺得難吃，你連原本的味道都回不去了。

你會怎麼做？在旁邊開一個實驗灶，用同樣的底湯，試著加花椒。這個實驗灶就是一個分支。

試了幾天，團隊覺得花椒版確實更好。這時候你把實驗灶的配方正式寫回標準食譜——這就是「合併」。從此以後，所有出餐都用新版本。

如果試了之後覺得不行？關掉實驗灶就好，標準食譜從頭到尾沒有被動過。

我們實際怎麼用

以這個網站為例，我們有兩條主要分支：

• main：正式上線的版本，客戶看到的就是這個
• dev：開發用的預覽版本，內部測試用

所有的修改都先推到 dev，在預覽環境確認沒問題之後，才合併到 main 上線。這個流程聽起來多了一道手續，但它讓我們幾乎不會在正式網站上出包。

偶爾我們也會開更多分支。比如同時有兩個人在改不同頁面，各自開一個分支，改完再分別合併回 dev。就像餐廳同時開兩個實驗灶，一個試花椒、一個試番茄，互不干擾。

一句話總結

git 分支就是讓你安心試錯的機制。它保護正式版本不被搞壞，同時讓你可以放心嘗試任何修改。改好了就合併，改壞了就丟掉，正式版永遠是穩定的那一份。