Monorepo 與 Polyrepo 深度指南 對比單一與多儲存庫架構並運用 Nx 工具提升效率

什麼是 Monorepo 與 Polyrepo？

Monorepo 與 Polyrepo 是軟體開發中兩種截然不同的程式碼管理策略。Monorepo (單一儲存庫) 是一種將多個專案、模組或服務（如前端、後端與共用元件）集中存放於同一個 Git 儲存庫中的做法，旨在優化「原子化提交 (Atomic Commits)」、簡化跨專案重構並達成依賴版本的一致性。相反地，Polyrepo (多儲存庫) 則是目前業界最常見的模式，將不同功能或職責的專案拆分為獨立的儲存庫管理，雖然有利於細粒度的權限控制與解耦，但常面臨跨 Repo 改動困難與依賴管理碎片化的挑戰。選擇適合的高品質策略能顯著提升開發者體驗 (DX) 與 CI/CD 的建置效率。

在版本控制系統中，Monorepo 和 Polyrepo 分別是兩種用來管理模組化程式碼的策略。以男女之間來說，就像是金錢是要分開管理 (Poly) 或是一起管理 (Mono)。即使一起管理，是單純全部丟在一起 (Monolith) 還是有做分類 (Monorepo) 也是關鍵。

👉 小編點評：該分開就早點分開，這個道理在哪似乎都適用。

接下來以前後端分離的 Web 開發為例，詳細分析這兩者。註：Monolith 是缺少規劃的 Monorepo，通常專案初期 POC 使用，基本上不用管。

1. Polyrepo：傳統的多儲存庫流派

把前端與後端分為兩個不同的 Repository，這是目前絕大多數專案的管理方式。

• 權限: 可按 Repo 設定細粒度權限。
• 專案管理: 責任歸屬切割容易，但難看全貌。
• CI/CD: 方便擴展且 DevOps 相關工具較齊全。
• Hotfix: 需要透過 PR 修改所有相關的程式。
• 重構: 跨專案重構需頻繁切換 Repo，且不易確認影響範圍。
• 共用元件挑戰: 測試流程繁瑣，包含 build 元件、手動改 node_modules、撰寫 Change Log 再發布等 6 大步驟。
• 套件版本管理: 多個專案需要分開管理。

Polyrepo 專案架構與問題

功能開發階段，前後端溝通成本較難下降？！

Polyrepo 前後端各自開工，當需要整合測試的時候就會需要：

1. 確認前後端目前是在哪個分支。
2. 確認前、後端各自跑起來的方法。
3. 確認如何把不同的分支整合對接。

共用元件的開發與測試流程較多手工且繁雜的部分

UI 共用元件通常會把元件封裝成 package 或透過 git 的 URL 來 npm install。

開發階段測試流程，維護共同相關 dependencies 成本較高：

1. npm run build 將元件建置。
2. 將目標專案 node_module 的 lib 改成新建置版本。
3. 在目標專案中實際測試。
4. 回到 UI 元件專案進行版號更動及 Change Log 撰寫。
5. 發布新版本。
6. 在目標專案中重新 npm install 新版。

Polyrepo CI/CD 流程 每次進版或退版較複雜

Polyrepo CI/CD 在做用戶端 APP 會很常區分 dev、uat、production 環境並以三或多個 branch 做區分。

2. Monorepo：單一儲存庫的優勢

將前後端原始碼放在同個 Repository。Google、Facebook 等大廠均採用此模式，Facebook 的 React 也是如此。

• 權限: 權限相對單一。
• 權限: 權限只有一種。
• 專案管理: 方便不懂架構的人發 Issue。
• CI/CD: 流程或是架構配置統一管理，統一退版較容易。
• Hotfix: 可透過「原子化提交」直接修改所有相關專案（如 API 欄位變動）。
• 重構: 原始碼距離近，方便大規模重構且易確認影響。
• 套件管理: 集中升級，能統一解決資安漏洞。

Monorepo 帶來的改變

• 統一設定: 初期需花時間設定 Config、Library。
• 開發加速: 開發一次元件，各專案立即可用，省下切換 Repo 的時間。

Monorepo 專案架構與問題

統一的設定及專案技術選型

• 初期需多點時間設定專案，Config、Library、Tech stack 會統一。
• CI/CD 流程 需要考慮更多情境。
• 可以立即知道修改程式碼後，相關專案是否正常運作。
• 開發一次元件，就能給各專案使用。
• 在專案之間檢視程式碼時，可以省下切換時間。

3. Nx：強大的 Monorepo 建置工具

Nx 是使用 TypeScript 撰寫的工具，提供「Smart, Fast, Extensible」的建置系統。內建支援三大前端框架與多種後端環境。

Nx 專案結構範例：

• apps/: 存放各專案。
• libs/: 存放共用的 Logic 或 UI Components。
• tools/: 自定義腳本。
• workspace.json / nx.json: 管理專案執行邏輯。

1
2
3
4
5
6
7
8

NxProject/
├── apps/
├── libs/
├── tools/
├── workspace.json
├── nx.json
├── package.json
└── tsconfig.base.json

推薦 VS Code 搭配指令：

• nx print-affected: 只建置受改動影響的專案。
• nx run-many -target=serve: 同時跑起前後端。
• nx graph: 視覺化專案相依性。

FAQ：儲存庫策略常見問題

Q1：Monorepo 會不會導致 Git 儲存庫變得太大而難以拉取 (Git Clone)？

A：確實會。 隨著程式碼量增加，Git 的效能會下降。為了解決這個問題，微軟開發了 VFS for Git，而 Google 內部則有自研的檔案系統。對於一般企業，建議使用像是 Nx 或 Turborepo 這種工具來達成「局部建置 (Incremental Build)」，並避免在 Repo 中存放大型二進位檔案（如影片或已編譯的套件）。

Q2：什麼時候該選 Polyrepo 而非 Monorepo？

A：如果您的團隊中有「外部承包商」或者是「需要嚴格權限隔離」的模組（例如核心支付邏輯 vs 形象官網），Polyrepo 是更安全的選擇。此外，如果專案之間完全獨立、沒有任何共用邏輯，強行併入 Monorepo 只會增加配置負擔。

Q3：Nx 與單純的 npm/yarn workspaces 有什麼不同？

A：Workspaces 只解決了「連結 local 套件」的問題。而 Nx 提供了「計算快取 (Computation Caching)」、「相依性分析圖」與「 affected 增量執行」。Nx 能知道哪些專案沒變過就直接從快取讀取 Build 結果，這在大型 Monorepo 中能節省 80% 以上的 CI 時間。

• ← 上一篇
• 下一篇 →