Monorepo vs Multirepo（一）：你的 repo 策略決定了團隊的痛苦程度

cover

你的 repo 策略決定了團隊的痛苦程度

一句話總結：Monorepo 和 Multirepo 不是誰比較好的問題，是你的團隊規模、服務耦合度、技術棧決定了哪個比較不痛。

結論先講：不要因為 Google 用 Monorepo 就跟著用。Google 有幾千個工程師和自研的建構系統。你的三人團隊用 Turborepo 已經夠了。如果不確定，從 Multirepo 開始——合在一起永遠比拆開來容易。

版本庫怎麼組織，看起來只是「程式碼放哪裡」的小問題，實際上影響深遠：CI/CD 速度、程式碼共享方式、團隊協作模式、部署獨立性——全部都被 repo 策略牽著走。

原子性變更：api-client 新增了一個欄位，web-app 和 admin 都要配合改。在 Multirepo 裡你要開三個 PR、三次 review、三次部署，任何一步漏掉都會版本不一致。在 Monorepo 裡一個 PR 全部搞定。

統一工具鏈：ESLint、TypeScript、Jest 的設定只維護一份。新人 clone 一個 repo 就能開發所有專案。

消除版本飄移：web-app 用 @company/utils@1.2.0、admin 用 @company/utils@1.3.0——Multirepo 裡這種版本飄移超常見。Monorepo 裡所有人永遠用同一版本。

CI 變慢：50 個套件 10 個 app，每次 push 都要全跑？雖然 Nx 和 Turborepo 有 affected analysis 和 task caching，但這些工具本身也有學習成本。

工具鏈複雜：要讓 Monorepo 順暢運作，你需要 Workspace 管理、建構排程、變更偵測、遠端快取。對三人小團隊來說，這些投資可能遠超收益。

爆炸半徑：一個糟糕的 commit 影響所有專案。shared/utils 的 breaking change 讓 10 個 app 同時壞掉。

耦合誘惑：Monorepo 讓跨專案引用太容易。工程師直接 import 另一個 app 的內部模組，而不是用定義好的 public API。久了邊界模糊，成了巨大泥球。

Git 效能：repo 太大的時候 git clone、git status 都會變慢。

選 Monorepo 的時機：服務緊密耦合、共用程式碼多、團隊 < 15 人、技術棧統一、發版節奏一致。

選 Multirepo 的時機：微服務邊界清晰、團隊 > 50 人、部署節奏不同、技術棧多元、需要團隊自治。

混合策略：大部分成熟團隊最終走到這裡——相關性高的放同一個 Monorepo、獨立性高的各自一個 repo。

微服務的精神是「各自獨立部署、獨立演進」。被鎖在 Monorepo 裡的微服務，CI/CD、部署節奏、技術選型都被其他服務牽制。

獨立 repo 的 CI 就是簡單的「lint → test → build → deploy」，不需要 affected analysis。壞了容易排查，因為範圍就在這個 repo 裡。

Monorepo 帶來原子性變更和統一工具鏈，但也帶來 CI 複雜度和耦合風險。Multirepo 帶來獨立性和簡單性，但犧牲了程式碼共享的便利。沒有銀彈，只有 trade-off。

下一篇看工具比較和 CI/CD 實戰設定。

系列文章：