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