前言

很多人在學 Git 分支時，會看到各種流程圖：Git Flow、GitHub Flow、GitLab Flow。

這些流程都有它們的使用情境，但如果專案很小、團隊人數也不多，一開始就套很複雜的分支策略，反而會讓大家卡在流程上。

我覺得分支策略的重點不是名字，而是團隊能不能穩定交付。

最小可用的分支概念

最簡單可以先分成兩種：

1
2
main    穩定版本
feature 開發中的功能分支

平常開發時，不直接在 main 上改。

而是開一個功能分支：

1
git checkout -b feature/add-login-page

完成後送 PR，review 沒問題再合回 main。

這樣至少可以避免開發中的程式直接污染穩定分支。

分支名稱要看得懂

分支名稱不用太華麗，但要能看出用途。

例如：

1
2
3
4
feature/add-search-page
fix/login-timeout
chore/update-dependencies
docs/cloudflare-pages-guide

看到名稱時，至少能知道這個分支大概在做什麼。

比起：

1
2
3
4
test
new
fix2
hikari-branch

前者在協作時會清楚很多。

不要讓分支活太久

分支放越久，越容易和主線差太多。

最後合併時可能會遇到：

  • 衝突變多。
  • 需求已經變了。
  • 原本的程式碼被別人重構了。
  • review 範圍太大，沒人想看。

所以功能分支最好小一點、短一點。

如果功能真的很大，可以拆成幾個階段合併，而不是一次丟出超大的 PR。

部署分支要和原始碼分清楚

像 Hexo 這種靜態網站產生器，常常會有兩種內容：

1
2
原始碼：Markdown、設定檔、主題、package.json
產物：build 出來的 HTML/CSS/JS

如果使用 hexo deploy，可以用不同分支區分：

1
2
master = 原始碼
main   = 部署產物

或更常見：

1
2
main     = 原始碼
gh-pages = 部署產物

重點不是分支名稱，而是原始碼和部署產物不要混在一起。

結語

分支策略不用一開始就追求完整規格。

我會先抓幾個原則：

  • 穩定分支保持乾淨。
  • 功能開分支做。
  • 分支名稱要有語意。
  • 分支不要放太久。
  • 原始碼和部署產物分開。

流程是為了幫團隊降低混亂，不是為了讓開發變得更有儀式感。