Здравствуйте, Miroff, Вы писали:

vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.

M>И в чем профит такого подхода?

В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.

А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.

M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.

Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.

M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.

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

Здравствуйте, Miroff, Вы писали:

vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.

M>И в чем профит такого подхода?

В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.

А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.

M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.

Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.

M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.

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

Моё имхо — монорепо это маст хэв для маленьких проектов (условно до 3 команд по 10 человек). Начиная с некоего среднего размера уже можно переходить на репозиторий для каждого компонента, т.к. всё ещё не такое большое, чтобы вызвать существенные проблемы с версиями, можно заставлять остальные проекты переходить на последние версии в разумное время и снимать их с поддержки. И начиная с некоего большого размера можно переходить назад на монорепо, уже в другом виде и с другими инструментами, т.к. когда в компании 1000 команд, с ними всеми уже общий язык находить будет маловероятно, в итоге либо всё превратится в болото, где нельзя сделать никакое изменение, либо людям даётся возможность сделать это своё изменение и пофиксить самостоятельно всех остальных.