Monorepo i multirepo: definicje bez skrótów myślowych
| Kryterium | Monorepo | Multirepo |
|---|---|---|
| Zmiany przekrojowe | Jeden commit lub PR może objąć wiele projektów | Zwykle kilka repozytoriów, wersji i PR |
| Zależności | Łatwiejsza centralizacja i wspólne reguły | Większa niezależność wersji |
| CI | Wymaga selektywnego grafu, cache i skalowania | Mniejszy naturalny zakres pojedynczego pipeline'u |
| Dostęp | Własność ścieżek przez reguły i review | Naturalna izolacja na poziomie repozytorium |
| Narzędzia | Więcej wspólnych standardów | Większa swoboda per projekt |
| Wydania | Mogą być niezależne, ale wymagają orkiestracji | Naturalnie oddzielne pipeline'y |
Monorepo to jedno repozytorium zawierające wiele logicznie oddzielnych projektów, takich jak aplikacje, usługi, biblioteki czy narzędzia. Multirepo, nazywane też polyrepo, utrzymuje te elementy w osobnych repozytoriach. Repozytorium jest granicą zarządzania kodem, a nie automatycznie granicą wdrożenia. [1][13][15]
Dlatego monorepo może zawierać dziesiątki niezależnie wdrażanych usług, a multirepo może przechowywać moduły jednego dużego systemu. Pomieszanie strategii repozytoriów z architekturą monolitu lub mikroserwisów prowadzi do błędnych decyzji.
Co pokazują badania Google: oba modele mają realne zalety
Badanie Google porównujące doświadczenia inżynierów pracujących z monolitycznymi repozytoriami i wieloma repozytoriami wskazało, że najważniejszą zaletą monorepo jest widoczność całej bazy kodu. Ułatwia ona odnajdywanie istniejących API, przykładów użycia oraz aktualizowanie kodu zależnego podczas migracji. Inżynierowie doceniali też scentralizowane zarządzanie zależnościami. [1]
To samo badanie wskazało zalety multirepo: większą swobodę wyboru narzędzi, mocniejsze granice dostępu i większą stabilność między projektami. Autorzy podkreślili również, że jakość narzędzi wokół repozytorium jest równie ważna jak sam model przechowywania kodu. [1]
Zmiany przekrojowe: największa praktyczna przewaga monorepo
Jeżeli jedna zmiana interfejsu wymaga jednoczesnej aktualizacji backendu, frontendu, bibliotek i testów, monorepo pozwala umieścić całość w jednym commicie lub pull requeście. Google wymienia możliwość automatycznego aktualizowania kodu zależnego podczas migracji API jako jedną z ważnych korzyści wspólnego repozytorium. [1][2]
W multirepo ta sama zmiana zwykle wymaga kolejności: aktualizacja producenta, wydanie nowej wersji, aktualizacja konsumentów i koordynacja kilku pull requestów. Można to automatyzować, ale granice repozytoriów pozostają granicami procesu integracyjnego.
Zależności i wersjonowanie: centralizacja kontra niezależność
Monorepo ułatwia utrzymywanie wspólnych wersji zależności i bezpośrednie odwołania między lokalnymi pakietami. Yarn Workspaces pozwalają pakietom w jednym projekcie odwoływać się do siebie, a Constraints mogą wymuszać zgodność wersji zależności lub pól `package.json` w całym workspace. [13][14]
Multirepo daje każdemu projektowi większą niezależność wersji i tempa aktualizacji, ale może prowadzić do rozjazdu wersji wspólnych bibliotek. Taki model działa dobrze, gdy kontrakty są stabilne, a artefakty są publikowane przez rejestry pakietów lub inne kontrolowane kanały.
CI w monorepo: pełny build przy każdym commicie to zły model
Duże monorepo nie powinno uruchamiać wszystkich testów i buildów po każdej zmianie. Nx `affected` używa historii Git oraz grafu projektów do wyznaczenia minimalnego zbioru projektów dotkniętych zmianą. Pozostałe zadania mogą być pominięte. [4]
Remote caching pozwala współdzielić wyniki już wykonanych zadań między maszynami deweloperskimi i CI, a rozproszone wykonanie dzieli pozostały graf zadań między kilka maszyn. Bazel rozwiązuje podobny problem poprzez zdalne wykonanie i cache, rozdzielając akcje buildów i testów na wiele węzłów. [5][7][8]
Multirepo i CI: prostszy zakres nie oznacza zerowej koordynacji
W multirepo pojedynczy pipeline z natury widzi mniejszy obszar kodu, dlatego łatwiej ograniczyć build i testy do jednego projektu. Ta prostota jest realną zaletą, szczególnie gdy usługi są słabo powiązane i mają osobne zespoły.
Koszt pojawia się przy zależnościach między repozytoriami. Zmiana wspólnej biblioteki lub kontraktu może wymagać publikacji artefaktu, aktualizacji kilku repozytoriów, zgodności wersji oraz dodatkowych testów integracyjnych. Google wskazuje stabilność jako zaletę multirepo, ale jednocześnie widoczność i automatyczne migracje jako przewagę monorepo. [1]
Granice architektoniczne: monorepo bez reguł szybko staje się problemem
Wspólne repozytorium nie powinno oznaczać dowolnych importów między każdym projektem. Nx pozwala deklaratywnie wymuszać granice modułów, między innymi przez tagi projektów i reguły zależności. Pozwala to blokować niepożądane importy i nieplanowane zależności między domenami. [6]
W multirepo część granic istnieje fizycznie, bo kod znajduje się w osobnych repozytoriach. To jednak nie zastępuje architektury: projekty nadal mogą tworzyć silne sprzężenia przez API, bazy danych, kolejki lub wspólne biblioteki.
Dostęp i bezpieczeństwo: tutaj multirepo często ma przewagę
GitHub nadaje role i uprawnienia na poziomie repozytorium, dlatego osobne repozytoria naturalnie pasują do sytuacji, w których różne zespoły lub kontraktorzy mają widzieć różne fragmenty kodu. Role mogą obejmować poziomy od Read do Admin. [11]
W monorepo CODEOWNERS oraz rulesets pozwalają wymuszać recenzje dla określonych ścieżek i zespołów, ale są mechanizmem własności i zatwierdzania zmian. Jeśli organizacja wymaga twardego rozdzielenia widoczności kodu między grupami, granica osobnego prywatnego repozytorium jest zwykle prostszym modelem dostępu. [10][12]
Wydania i wdrożenia: jedno repo nie oznacza jednego release
Yarn opisuje workspace jako zestaw pakietów jednego projektu i wprost wskazuje, że pakiety mogą być wdrażane niezależnie. Gradle multi-project również rozdziela system na logiczne subprojekty z własnymi zależnościami i zadaniami. [13][15]
Monorepo może więc mieć osobne pipeline'y i wersje dla aplikacji, usług oraz bibliotek. Multirepo daje tę niezależność domyślnie, ale wymaga mocniejszej automatyzacji, gdy wiele wydań musi zostać skoordynowanych jako jedna zmiana produktu.
Rozmiar repozytorium i Git: duże monorepo wymaga świadomej obsługi
Google opisał własne monorepo liczące miliardy linii kodu, ale jednocześnie podkreślał wykorzystanie niestandardowej infrastruktury. Ten przykład dowodzi, że monorepo może skalować się bardzo wysoko, a nie że taki model jest bezkosztowy lub właściwy dla każdej firmy. [2]
Aktualny Git oferuje `sparse-checkout`, który ogranicza katalog roboczy do wybranej części śledzonych plików. Jest to jedno z narzędzi pomagających pracować z dużymi repozytoriami, ale dokumentacja Git nadal oznacza zachowanie sparse checkout jako eksperymentalne i mogące się zmieniać. [9]
Narzędzia w 2026 zmniejszają koszt obu podejść
W ekosystemie JavaScript monorepo ma natywne wsparcie workspaces, grafów projektów, cache i ograniczania zakresu CI. W JVM Gradle wspiera multi-project builds, a composite builds pozwalają połączyć kilka niezależnych buildów i rozwijać je razem bez wcześniejszego publikowania artefaktów. [13][15][16]
To ostatnie jest ważne także dla multirepo: osobne repozytoria nie muszą oznaczać całkowicie rozdzielonego środowiska lokalnego. Composite builds są przykładem mechanizmu, który pozwala zachować osobne granice projektu, a jednocześnie testować je wspólnie. [16]
AI coding agents dodają nowy argument do decyzji
W dokumentacji z 2026 Nx argumentuje, że agenci programistyczni korzystają z pełnego kontekstu monorepo, grafu projektów, szybkich testów dotkniętego obszaru i automatycznie egzekwowanych granic. Jest to perspektywa dostawcy narzędzia monorepo, więc nie należy traktować jej jako niezależnego dowodu przewagi. [3]
Praktycznie wspólny kontekst może ułatwiać agentowi zmianę kontraktu i jego konsumentów w jednym zadaniu. Z drugiej strony multirepo ogranicza zakres kodu dostępnego w pojedynczej sesji i może lepiej odpowiadać organizacjom, które chcą minimalizować zakres uprawnień agentów. To dodatkowe kryterium, nie argument rozstrzygający.
Kiedy wybrać monorepo
Monorepo jest szczególnie sensowne, gdy aplikacje i biblioteki często zmieniają się razem, wiele zespołów korzysta ze wspólnych komponentów, a organizacja potrzebuje atomowych refaktoryzacji i jednej widocznej mapy zależności. Badanie Google wspiera właśnie te korzyści: widoczność, odnajdywanie istniejących API, przykłady użycia, migracje i centralizację zależności. [1]
Warunkiem jest inwestycja w granice modułów, selektywne CI, cache, właścicieli kodu i automatyzację. Bez tych elementów wzrost repozytorium może jedynie przenieść złożoność z wielu repozytoriów do jednego ogromnego pipeline'u. [4][5][6]
- Częste zmiany przekrojowe między frontendem, backendem i bibliotekami.
- Dużo współdzielonego kodu i wspólnych standardów.
- Potrzeba atomowych refaktoryzacji.
- Jednolity lub kompatybilny stos narzędzi.
- Gotowość do inwestycji w graf zależności, cache i selektywne CI.
- Brak wymogu twardej izolacji widoczności kodu pomiędzy większością zespołów.
Kiedy wybrać multirepo
Multirepo jest mocnym wyborem, gdy domeny mają wyraźne granice, zespoły potrzebują niezależnych stosów technologicznych, cykli życia i uprawnień, a zmiany przekrojowe są stosunkowo rzadkie. Google wskazał elastyczność narzędzi, kontrolę dostępu i stabilność jako istotne zalety takiego modelu. [1]
Dodatkowym sygnałem jest sytuacja, w której część kodu ma ograniczoną widoczność, inne wymagania compliance lub osobne grono kontraktorów. Repozytoryjny model ról GitHub bezpośrednio wspiera takie rozdzielenie. [11]
- Silna autonomia zespołów i odrębne cykle życia.
- Różne języki, narzędzia i procesy buildowania.
- Twarde wymagania dostępu lub compliance.
- Rzadkie zmiany obejmujące wiele projektów jednocześnie.
- Stabilne kontrakty i dojrzałe zarządzanie wersjami.
- Niezależne pipeline'y są ważniejsze niż wspólny graf całej platformy.
Model hybrydowy i praktyczna decyzja w 2026
| Sytuacja | Domyślny kierunek | Dlaczego |
|---|---|---|
| Częste zmiany kilku aplikacji i bibliotek naraz | Monorepo | Atomowe refaktoryzacje i wspólny graf zależności |
| Różne zespoły nie mogą widzieć całego kodu | Multirepo | Repozytoryjny model uprawnień upraszcza izolację |
| Zespoły wymagają odmiennych toolchainów i lifecycle | Multirepo | Mniej centralnej standaryzacji |
| Silnie współdzielona platforma i biblioteki | Monorepo | Lepsza widoczność i centralizacja zależności |
| Wiele małych usług | Zależy | Decyduje częstotliwość wspólnych zmian, nie liczba usług |
| Mieszane wymagania domen, dostępu i technologii | Hybrydowo | Domenowe monorepo plus wybrane osobne repozytoria |
Wybór nie musi być binarny. Organizacja może utrzymywać domenowe monorepo dla silnie powiązanych produktów, osobne repozytoria dla komponentów bezpieczeństwa lub klientów oraz wspólne pakiety publikowane przez rejestr. Gradle composite builds pokazują nawet techniczny model łączenia niezależnych buildów do wspólnej pracy lokalnej. [16]
Przed migracją warto policzyć częstotliwość zmian przekrojowych, liczbę wspólnych zależności, czas CI, liczbę repozytoriów dotykanych przez typową funkcję, wymagania dostępu oraz koszt koordynacji wydań. Dopiero te dane powinny zdecydować o topologii repozytoriów.
