2022 了，你還不知道 Multi-repo 和 Mono-repo 的區別么？
Multi-repo 和 Mono-repo 是 Git 托管代碼的兩種策略，我們討論下兩者的策略以及其利弊。
引言
大多數現代項目都是在 Git 上管理和托管的。Git 已經成為來自世界各地的分布式源代碼管理、版本控制和協作的標準平臺。Git 是快速和高效的，主要有兩種方法來托管和管理 Git 代碼:
- Mono-repo
- Multi-repo
在深入研究這些方法之前，讓我們先了解一下 Repo 是如何工作的。
Repos 是什么?
倉庫(Repo)包含項目的所有文件夾和文件。它還包含關于用戶、人和計算機的信息。
Git 倉庫數據受版本控制，Repo 可以由個人或團隊成員擁有。
Git 倉庫可以是公開的，私人的，或者是內部的。GitHub 是 Git 倉庫的一個托管服務，并且有一個用戶界面。
Git 提供了版本控制和代碼共享功能，Git 的特別之處在于，如果開發人員想對他們的文件做一些修改，他們可以將整個存儲庫復制到他們的本地系統中。因此，即使開發人員沒有對特定項目的寫入權限，他們也可以在本地復制內容并修改它們(我們稱為 forking)。
此外，如果開發人員希望共享本地所做的更改，他們可以向項目所有者發送一個 “pull request”。
一個項目可以只有一個服務。如果你的項目有多個工作流，你可以為每個工作流創建多個服務。大多數開發人員喜歡將較大的項目拆分為具有一個或多個功能的較小的獨立服務。每個服務都可以解決各種業務問題。隨著 serverless 框架的流行，用戶可以將功能作為服務訪問。
一旦你創建了這些函數——作為服務并部署它們，下一步就是對它們構造和版本控制——你可以將所有的服務放在一個存儲庫(mono-repo)中，或者為你擁有的每個服務擁有一個單獨的存儲庫(multi-repo) !
什么是 Mono-repo?
在 mono-repo 方法中，你可以將所有服務保存在單一(mono)存儲庫中。你仍然可以獨立地部署和管理每個服務。這些服務可以共享公共庫和代碼。
像 Facebook、 Google 和 Dropbox 這樣的公司都使用 Mono-repo。
Mono-repo 的優勢
Mon-repo 方式有許多優點：
- 存儲所有項目代碼的單獨位置，團隊中的每個人都可以訪問。
- 易于重用和共享代碼，與團隊合作。
- 很容易理解你的變更對整個項目的影響。
- 代碼重構和代碼大變更的最佳選擇。
- 團隊成員可以獲得整個項目的總體視圖。
- 易于管理依賴關系。
Mono-repo 的劣勢
當然，Mono-repo 也有一些缺點，主要表現在性能上。如果你的項目增長，每隔一天都會添加更多的文件，那么 git checkout、pull 和其他操作可能變得緩慢，以及文件搜索可能需要更長的時間。
此外，如果你為你的項目雇傭了許多獨立的承包商，那么讓他們訪問整個代碼庫可能不那么安全。
此外，實現持續部署(Continuous deployation，CD)也很困難，因為許多人可以合入他們的更改，而持續集成(Continuous Integration，CI)系統可能需要進行多次重構。
使用 Mono-repo 的大公司都有自定義工具來處理擴展問題。例如，Facebook 使用自定義文件系統和源代碼控制。
什么是 Multi-repo?
在 Multi-repo 方法中，存在多個存儲庫，它們承載一個項目的多個庫和服務。如果服務發生更改，開發人員只需重新構建該服務，而不需要構建整個項目。個人和團隊可以從事他們特定的服務，他們只能訪問他們有權限的服務。
像 Netflix 和 Amazon 這樣的公司使用 Multi-repo。
Multi-repo 的優勢?
采用 Multi-repo 的公司數量遠遠多于采用 Mono-repo 的公司，原因如下:
- 每個服務和庫都有自己的版本控制。
- 代碼 checkout 和 pull 是小型且獨立的，因此即使項目規模增大，也不存在性能問題。
- 團隊可以獨立工作，不需要訪問整個代碼庫。
- 更快的開發和靈活性。
- 每個服務都可以單獨發版，并有自己的部署周期，從而使 CI 和 CD 更易于實現。
- 更好的權限訪問控制——所有的團隊不需要完全訪問所有的庫——需要的時候，再獲得讀訪問權限。
Multi-repo 的劣勢
- 跨服務和項目使用的公共依賴和庫必須定期同步以獲得最新版本。
- 某種程度上鼓勵孤立文化，導致重復代碼和各個團隊試圖解決相同問題。
- 每個團隊可能遵循不同的一組最佳實踐來編寫代碼，從而導致難以遵循通用的最佳實踐。
Mono Repo 和 Multi Repo 的區別
讓我們來概括 Mono Repo 和 Multi Repo 的區別:
Mono-repo | Multi-repo |
一個組織的所有項目的所有代碼都駐留在中央存儲庫中(譯者：這里感覺可能有點絕對) | 每個服務和項目都有一個單獨的存儲庫 |
團隊可以一起協作和工作; 他們可以看到彼此的變化 | 團隊可以自主工作; 個人的變更不會影響其他團隊或項目的變更 |
每個人都可以訪問整個項目結構 | 管理員可以將訪問控制限制到開發人員需要訪問的項目或服務 |
如果項目規模不斷增長，則可能會出現并放大問題 | 良好的性能，因為有限的代碼和較小的服務單元 |
難以實現持續部署(CD)和持續集成(CI) | 開發人員可以很容易地實現 CD 和 CI，因為他們可以獨立地構建服務 |
開發人員可以輕松地共享庫、 api 和其他在中央存儲庫中更新的公共代碼 | 對庫和其他常見代碼的任何更改都應該定期同步，以避免以后出現問題 |
總結
Mono-repo 和 Multi-repo 同樣流行，哪一個更好取決于你的項目大小、項目需求以及你需要的版本控制和訪問控制級別。
Mono-repo 側重一致性，而 Multi-repo 側重于解耦。在 Mono-repo 中，整個團隊可以看到某一個人完成的更改，而 multi-repo 為每個團隊創建一個單獨的 repo，這些團隊只能訪問所需的倉庫。如果你想為你的項目使用 mono-repo 和 multi-repo 的組合，你可以使用 meta，一個管理多個項目和庫的工具。
原文地址：Mono-Repo vs Multi-Repo: Throwing Light On Code Repository Strategies
原文作者：Butterfly Thoughts
譯者：Gopal
