為何想做CI的你，根本不該使用 Gitflow?

今天在 Build School 上課時發生了一件事，讓我想了想之後，還是決定寫篇文。

事情是這樣的。

上課時，我問學員：「如果有一個敏捷團隊，裡面大概 5-7 位成員，在一個迭代中同時開發 3-5 張需求卡片，你們覺得應該切幾個 feature branch?」

本來以為會聽到各種答案。
有人會按功能切、會按人頭切、或是按模組切…，因為我曾經聽過各式各樣的回答。

結果，他們所有人異口同聲：「只切一個分支。」
我愣了一下。「只切一個？」
「對，一個。」

這群學員才剛學 Git 沒多久，怎麼得出這個『違反常理』的結論的？上了這麼多年課，每次談到這個議題，學員都還可以跟我糾結半天，討論到底要不要用 Gitflow。

後來，助教跟我解釋，原來他們之前讓學員自己做了實驗。

什麼實驗?

實驗很簡單，因為反正要做專題，所以把學員幾個人分一組，讓他們用不同的分支策略跑幾個迭代。有些組按人切分支，有些按功能切，有些混著切。然後看看哪種方式最順。

結果呢？

用多分支的組，第一個迭代還算順利，大家各寫各的，感覺井然有序。但整合的時候就開始出事了。功能 A 做完了，但要等 B 跟 C 才能 merge。有人幾天沒事做，只能坐著等。

到第二個迭代，問題更大。大家在自己的分支上寫了一段時間，最後 merge 時才發現衝突一堆。有些衝突好解，但有些是邏輯上的衝突，或是使用了同樣功能的不同套件，兩個人改了同一個模組的不同地方，單獨看都沒問題，合起來就爆了。

第三個迭代，有人開始崩潰。明明功能做完、測試也過了，但因為流程卡在 release branch，要等到迭代結束才能部署。一個小 bug 改了五分鐘，卻要三天才能上線。更慘的是，有人說：「程式碼寫完過了很久才整合，開始忘記當初為什麼要這樣寫了。」

最後，讓他們自己試試看：如果大家都在同一個分支上開發會怎樣？

結果出乎所有人的意料之外。
衝突變少了(其實是變多了，但因為每天都在整合，有問題馬上發現，立刻解決，所以花在解決衝突的時間反而變少了)。部署變快了，一個小功能做完，就能立刻上線。整個團隊的節奏順暢很多，不用再有人乾等。

助教說：「他們自己體驗過就懂了，不用我們特別去教。」
聽完之後，我想了很久。

DORA 指標

其實他們體驗到的，就是 Google 研究出來的 DORA 指標在講的事情。

DORA 是什麼？就是用四個數字來衡量團隊的交付能力。部署頻率、變更前置時間、變更失敗率、平均修復時間。

高績效團隊通常可以一周部署數次，甚至一天部署好幾次，從提交到上線只要數小時，變更失敗率低於 15%，出現問題一小時內就能修好(並且完成上版)。

當技術團隊改用單一分支之後，所有DORA指標數字都變好了。

從每月部署一次可以變成每天數次。從提交後 3-5 天才能上線變成幾小時就可以上線。因為每次改動的顆粒度小，問題更容易被發現(被凸顯)和修復。出問題時也很好處理，因為改動小、歷史歷史軌跡清晰，更不可能有人忘記自己到底為了什麼寫這段code。

但，這次不是我跟學員們講的理論，而是他們實做出來的結論。

持續整合(continuous integration, CI) 的本意

我得先說，Git Flow 不一定有錯。

2010 年 Vincent Driessen 剛提出 Git Flow 的時候，它確實解決了很多問題。當時根本還沒有 CI/CD、沒有自動化測試、部署週期動輒幾週甚至幾個月。在那種環境下，你需要 develop branch 來保護主線、需要feature branches 因為開發週期較長、需要 release branch 來做漫長的測試、需要 hotfix branch 來處理緊急修復。

但現在不一樣了。

我們有自動化測試可以在每次提交時驗證程式碼。
有 CI/CD pipeline 可以幾分鐘內將 artifacts 部署到Production環境。
有 Feature flags 可以不用切分支就能控制功能發佈(也就是發佈、但不上線)。
有mornitor和alert機制可以快速發現問題和rollback。
(現在還有AI加速器…)

在這種環境下，Git Flow 的複雜度反而變成團隊不必要的負擔。

Trunk-Based Development 的概念很單純：大家都在共同的主線上開發，或者用很短的分支（不到1-2天）開發，並且頻繁整合回主線。

聽起來很激進是吧？
但這才是「持續整合(continuous integration, CI)」的本意。
如果你的程式碼在分支(或是自己的電腦)上放了一週才跟其他人整合，這哪裡是持續整合？根本就是持續隱藏程式碼。

CI(持續整合)，是指你的程式碼頻繁的跟其他人整合在一起，時時刻刻。
但如果你用了 gitflow，不要跟人家說你有做CI，因為你沒有。

CI(持續整合)實踐的方式會很難嗎? 也不會。
小步前進，每次改動保持最小的顆粒度，幾小時就整合一次。用 自動化 CI Pipeline 並且做各種安全性掃描以確保不會破壞主線的品質。而未完成的功能則用 Feature flags 來控制。出問題就立刻rollback，反正每次改動都很小，小到你可以立刻復原。

如果團隊還不習慣直接在主線上開發，GitHub Flow 則是個很好的過渡選項。切個短分支，寫程式碼，發 PR，Code Review 加測試，同時運行 PR 觸發的自動化 Pipeline 做各種安全性掃描，然後在確認沒問題之後合併回主線，接著自動部署到正式機(或pre-prod)。重點是顆粒度「小」、週期「短」，以小時計算，不是天或週。

---

看著學員們那種「這不是理所當然嗎?」的表情，我突然意識到：
因為，他們還沒有被「Gitflow 是業界標準」所綁架。沒有因為「大家都這樣做」就照著做。

他們自己用實驗證明了什麼對他們有用。
是不是有人說過一句話：Best practices aren’t always best for you.

最難的不是學習複雜的技術，而是放下對複雜的執著。

過去我們花太多時間學習怎麼管理複雜度，怎麼處理多分支、怎麼解衝突、怎麼協調發布，但卻很少問：「這些複雜真的有必要嗎？」

Git Flow 教我們怎麼管理複雜度。
但真正厲害(和有價值)的，其實是直接消除根本不必要的複雜度。

---

後記：

「如果你的團隊還在糾結該用哪種分支策略，請先問自己一個關鍵問題：『我們多久能將程式碼部署到Production一次？』

如果你的答案是每週或更久，那麼你的團隊首要應解決的不是分支策略，而是如何提升交付能力。因為在低頻率交付的環境下，任何複雜的分支模型（如 Gitflow）都可能加劇整合與發布的困難。

如果你的答案是每天甚至更頻繁，那麼專注於主幹開發 (Trunk-Based Development, TBD) 或 GitHub Flow 等輕量級策略，將能最大化你的開發效率。

交付頻率當然只是手段，不是目的。
真正的重點是讓你的團隊有能力可以更快交付價值，更快的修復問題。

這才是 DORA 指標想告訴你的事。

後記的後記：

看到許多團隊口中暢談 DORA 指標，但卻死不肯改變行之多年的 Gitflow 流程，不覺令人莞爾。