鐘擺效應——歷史教你的務實選擇
一句話總結：版本庫策略的演進是一個鐘擺——從全放一起、拆成微服務、合回 Monorepo、再到務實的混合策略。理解這個擺動，你就不會追風了。
結論先講：如果你現在問我「該用 Monorepo 還是 Multirepo」，我的答案是「看情況」——但如果你真的不知道，從 Multirepo 開始，因為合在一起永遠比拆開來容易。
版本庫策略的四個時代
階段一（2000s-2010s）：什麼都放一起。一個 repo 一個 app，前端後端 shared library 全在一起。本質上就是未經管理的 Monorepo。問題：沒有模組邊界，everything depends on everything。
階段二（2010s-2015s）：拆成微服務 + Multirepo。微服務興起，每個服務一個 repo。帶來了部署獨立性和團隊自治。問題：跨服務的變更痛苦、版本飄移嚴重、工具鏈各自為政。
階段三（2015s-2020s）：看到 Google 用 Monorepo，我們也來。Lerna、Nx、Turborepo 成熟了，大家開始把東西合回去。問題：CI 變慢、工具鏈變複雜、團隊自治被限制。
階段四（2020s-現在）：務實的混合策略。經歷過前面的洗禮後，越來越多團隊走向混合——相關性高的放同一個 Monorepo，獨立性高的各自一個 repo。
這個鐘擺告訴我們：沒有終極答案，只有當下最適合的選擇。
混合策略長什麼樣？
一個實際的例子：
- Monorepo A：前端應用群（web、admin、mobile）+ 共用 UI 元件 + 工具函式
- Monorepo B：後端微服務群 + 共用 proto 定義
- 獨立 Repo C：ML Pipeline（完全不同的技術棧）
- 獨立 Repo D：Infrastructure as Code（SRE 團隊獨立管理）
相關的放一起、不相關的分開。簡單、務實、不追風。
決策前問自己這些問題
- 團隊多少人？超過 30 人可能需要 Multirepo 的自治優勢
- 服務之間有多少共用程式碼？共用越多，Monorepo 優勢越大
- 部署節奏一致嗎？不一致的話 Monorepo 會造成不必要的牽制
- 有能力維護 Monorepo 工具鏈嗎？
- CI 能在 10 分鐘內完成嗎？
- 團隊熟悉 Nx / Turborepo 嗎？
系列總結
| 面向 | Monorepo | Multirepo |
|---|---|---|
| 原子性變更 | 天然支援 | 需要跨 repo 協調 |
| CI/CD 複雜度 | 高 | 低 |
| 程式碼共享 | 簡單直接 | 需要發佈套件 |
| 團隊自治 | 較受限 | 天然支援 |
| 工具鏈投資 | 高 | 低 |
| 新人上手 | Clone 一次搞定 | 需要 clone 多個 |
不要因為 Google 用 Monorepo 就跟著用，不要因為聽起來很酷就跟著用。評估你的實際情況，做最務實的選擇。
系列文章：
- Monorepo vs Multirepo（一）：策略比較
- CD
- 你在這裡 → Monorepo vs Multirepo（三）：演進歷史與務實選擇
延伸閱讀：
「最好的 repo 策略不是最潮的那個，是讓你的團隊最不痛苦的那個。」