Монолитные репозитории в Git

Спасибо, учту Ваше пожелание. Есть пара хороших статей на эту тему, обязательно до них доберусь.

Вот. Кое-какие мысли по поводу и некоторое обсуждение. Может, пригодится.

Неправда Ваша, работа кипит.

BitBucket Server 4.3 уже поддерживает LFS.

Вы уже как-то определитесь, они единое логическое приложение или таки не связаны.
Думаю, это следует читать как «содержит набор сервисов, фреймворков и библиотек, написанных специально для приложения и нигде более в свободном виде не использующихся». Они вроде как и не связаны, но и по-отдельности никому не нужны.

Важна даже не логическая связанность (части одного приложения). Git следит на всем деревом сразу. То есть вопрос о том, надо ли всё держать в одном репозитории или следует разбить на несколько, можно переформулировать следующим образом: есть ли смысл в том, чтобы разные части имели разные версии? Если да, то их следует поместить в отдельные репозитории, если нет — то в разные. Например, вполне можно представить случай, когда есть Сервер v.4 годовой давности и Сервис v.10, выпущенный месяц назад. Однако, если поставляется сразу цельное решение, то вполне можно и все сваливать в одну кучу.
Проблема, в общем, в том, что Git продолжают считать просто интеллектуальным rsynс'ом по типу SVN: «Я жмякаю Commit. Мои изменения улетают куда-то на сервер. После этого Вася может их забрать, а я могу не волноваться, что мой жёсткий диск сломается». Коммиты как таковые не считаются чем-то самостоятельным, скорее отражением истории. Отсюда и естественность мысли о том, что Отдел №1 может возиться в своей части репозитория, а Отдел №2 — в своей, вроде бы не должны мешать, поэтому достаточно только одного репозитория. И ветки тоже не нужны, потому что история линейна как ось времени, а ветки только всё запутывают. В то же время Git считает коммиты версиями репозитория в целом, а не его отдельных файликов или частей.
В Линуксе тоже много частей и тысячи разработчиков, но это не мешает им всем работать в одном логическом репозитории. Как им это удаётся? Просто все не коммитят сразу в master центрального репозитория.

В том же Subversion мультикомпонентные проекты нормально живут в рамках одного репозитория. Нет проблем ни с размерами (при клонировании отдельной директории не копируется ни чего лишнего и разработчик может делать любой срез из исходников проекта, который посчитает нужным), ни с версионированием (грубо говоря, в каждой директории своя история).
А вот у решивших мигрировать из SVN в Git подобные вопросы возникают постоянно: и с размером, ведь Git не может не копировать весь репозиторий, и с версионированием отдельных частей, поскольку история в git не связана с файловой структурой проекта. Решение о том, чтобы ввести понятие компонентов для каких-то срезов дерева исходников, чтобы разложить проект на отдельные git репозитории, не всегда подходит. К тому же это создает новые проблемы с администрированием такой структуры.

Тут как не повернись проблема будет. Вот у нас есть проект из 8 микросервисов и число их растёт. Напрямую они друг от друга не зависят никак, только API разделяют. Либо мы всё это суём в один проект и один репозиторий и тогда имеет простоту миграции API, либо по разным репозиториям и тогда не имеем проблемы быстроразрастающегося репозитория. Но имеем целый геморрой с любым изменением в API.

не, тормозит еще больше гита… по крайней мере мы от него отказались недавно

Как упомянуто в статье, Mercurial тоже надо (было) допиливать для действительно большого репозитория. И эта доработка, на самом деле, решает лишь часть проблемы.

Упс… вот это видео более конкретно — Why Google Stores Billions of Lines of Code in a Single Repository

Babel отличный пример почему монорепо — не зло, если использовать с умом. Там все очень взаимосвязано, а отдельные пакеты очень маленькие. Менеджить такое в отдельных репозиториях была бы такая боль, что лучше об этом вовсе не думать даже.