Про Гугл и условный FB менее интересно обсуждать тк у них условно бесконечное количество ресурсов на поддержку тулинга и инфраструктуры. Интереснее посмотреть как живут проекты среднего размера - когда стандартные тулзы уже не очень работают, а кастомные ещё нет денег и времени разрабатывать.
И тут начинаются разные подходы с “шардированием” монорепы по максимально независимым кускам. Например, в Uber отдельные монорепы под Go, Java и Mobile
Есть Wix, которые побили весь код на пачку монореп, а зависимости между монорепами сделали по latest - что в целом так себе, но тк между проектами мало пересечений, то вроде работает

я все делю на мультирепы и делаю градл плагин чтобы зависимости ментейнить для микросервисов. базово я бы делал его и в монорепо скорее всего, только не плагином возможно

Да всё то же самое. Гугл пробовал для Андроида что-то такое сделать и оно вроде даже работает, просто я не настоящий сварщик по Андроиду.
У тебя всё равно будут проблемы атомарности коммитов + перемещения кода из одной части репозитория в другую без потери истории
Плюс все задачи, которые требуют операций над всем кодом, будут обёрнуты в for repo in repos: do some logic

че за атомарность коммита если у тебя развезено на микросервисы?

тебе и не нужно атомарно и невозможно атомарно обновить > 1

ну например ты можешь атомарно поменять тесты и код, producer и concumer в API

мы же не делим монолит на мультирепо, правда?

это не во всех проектах надо, но часто надо

ну ты задеплоить все равно атомарно не сможешь это, какую проблему мы решаем 1им коммитом?

я может не сталкивался. не пойму никак)

это может быть полезно (много репозиториев) если у нас есть продукт, который мы ставим разным заказчикам и он немного кастомный под них

но тут и сама такая ситуация напрягает (разный код под разных заказчиков)

Пример: есть в Яндексе либа, которая строит из запроса дерево, по которому происходит поиск и поиск по рекламе. Это библиотека, потому что latency и вот это всё.
Пока поиск, реклама и либа живут в одной репе, все изменения в либе требуют соответствующих изменений в поиске и рекламе. А когда реклама отъехала в отдельную репу, то достаточно быстро либа развилась до того состояния, когда переехать на новую версию уже больно. В итоге мы имеем апстрим в Поиске, legacy-версию в Рекламе. И это плохо не только потому что качество в рекламе ниже и денег меньше, а ещё и потому что у тебя поиск и реклама разные результаты начинают показывать

ну это можно и на этапе сборки рулить

тут я думаю бранчи будут лучше работать

нельзя

ай? если там прям в модуле код другой - то на этапе установки настройками и переключением стратегий
а если модули другие  - на этапе сборки под каждого заказчика свой артефакт

plugin based архитектура, хз

ну если мы про форки в соседних репо я бы до последнего пытался избежать, а потом менял бы работодателя:) если возможно

я сейчас долгое развёрнутое объяснение писать не смогу тк убегаю. так просто оно не работает, мир - сложная штука. ты либо начинаешь жёстко следить что все переезжают на апстрим-версию и жестоко бьёшь палками тех кто нет (и потом ещё геморроишься с хотфиксами этой версии для багов, которые находятся  отложенно на процессе бампа версии у всех зависимостей), либо оно так не работает