之前看了一位git大神的演講，提及一個叫MONO Repository的使用情況。後期找資料之後，才發現到這是一個公司成長後的一個重大的挑戰。

何謂MONO Repository

git的傳統，就是為每一個獨立的專案，建立一個新的Repository (中譯：倉庫)。這個很直觀，獨立專案，獨立管理。從零開始有很多好處，Repo體積通常會小一點，因為其內的東西都是緊密相關。做更新處理時，維護人員也更清楚自己的影響程度。這種架構方式，就叫Multi Repository。基本上，大家預設也是會走這個模式。

但當公司規模一直變大，多個專案可能不再獨立，各個專案或多或少都有一些關聯性。當任一專案更新，都有機會影響到其他人。如果公司使用Micro Service （微服務），就更有機會提早遇到。每次更新時，要跨專案地找出影響範圍原本就已經不容易，現在每個專案獨立地存放在不同的倉庫中，每個倉庫的更新速度不一樣，想要找到合適的地方、合適的時間點推出更新，更是困難。

所以，就有公司就提出，將所有專案都放在同一個Mono Repository中，方便用工具去檢查更新影響。相比Multi Repository，這樣做還可以保證同一個改動可以發生中同一個Commit中，可以讓跨專案的團隊可以即時合作（強逼修改別人的專案）。但這樣使一定會有很技術問題出現。跨專案團隊不可能每個專案都熟悉，因為不熟悉而引起的副作用一定會有，所以Main / Master分支出現有缺陷的機會提高了。亦有人提出，使用Mono架構，還必要使用trunk base分支模式。也就是那些新功能，雖然要創建分支開發，但亦要盡早整合到Main / Master中。這才能讓不同的團隊盡早知道問題，並解決問題。

除了開發模式更具挑戰外，Mono架構對git的效能也有很大影響。因為多專案混合，Repository的大小基本都會很大。每個git指令都會變慢，所以必需做一些週期性的cache，讓git graph, git status這樣日常操作變得暢順。同樣地，持續整合/發佈需要作出調整。不過這些筆者就不在這邊詳述了，有興趣朋友可以到git 大神的Youtube觀看。

So You Think You Know Git - FOSDEM 2024

註：據筆者的資料搜集，很多大公司（Software龍頭）都有使用Mono Repository去做集中管理。只不過筆者不知道如何Fact check，就不在這裏提了。