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

[musuk]

Тут бы ещё рассказ про то, как готовить git submodules не помешал.

[detouched]

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

[semenyakinVS]

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

[bak]

Ещё бы они начали поддерживать lfs на самом bitbucket. Уже год тикет висит а подвижек не видно.

[detouched]

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

[slonopotamus]

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

Репозиторий содержит набор сервисов, фреймворков и библиотек, составляющих единое логическое приложение.

Вы уже как-то определитесь, они единое логическое приложение или таки не связаны.

[wizardsd]

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

[firegurafiku]

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

[ilammy]

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

[gearbox]

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

Здравая абстракция, запомню. Но есть ситуации когда и она может сбоить. Например мобильная версия приложения под разные платформы + сайт + расширения для броузеров. Логически можно разделить, по факту могут совместно использоваться ресурсы (картинки, шрифты). Сильно не копал в эту сторону но вроде у svn была возможность подключать один репозиторий как часть другого. В общем, на мой дилетантский взгляд — системам версионного контроля нужно нечто вроде view у баз данных. Сделал вьюху от репы, в которой только тебе нужные файлы и работаешь. Если коммиты других разрабов твое не трогают — ты о них и не знаешь. Ели кто что зацепил — делаешь pull и смотришь.

[funca]

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

[asm0dey]

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

[detouched]

Есть подозрение, что 8 — это маленькое число, и если Вам удобнее держать их вместе, то надо так и делать, пока что не опасаясь разрастания репозитория, — достаточно помнить о бинарных файлах (в смысле, что добавлять их надо аккуратно или хранить в LFS).
Проблемы, связанные с количеством файлов, коммитов и веток становятся заметными при очень больших абсолютных значениях.

[PavelMSTU]

Может быть решение проблемы "монолитного репозитория" — это Mercurial?

[DragonFire]

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

[PavelMSTU]

Чем же тормозит когда данные хранятся инкрементально?..
Один коммит связан только со своим предком.

На моем опыте — проблем не было.
31 проект в одной папочке, каждый примерно по 45-80 *.py файлов…
Полет нормальный.

Единственный важный нюанс: на Win Mercurial лучше не ставить, мягко говоря… Два раза были проблемы с кодировками… Собственный опыт… :(

Вот хороший пост про отличия Mercurial и Git:https://habrahabr.ru/post/168675/

[detouched]

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

[SowingSadness]

А какие не решает?

[detouched]

Я имел в виду то, что созданные в Facebook расширения опираются на наличие memcache — он уже был у FB для других целей, так что его просто переиспользовали. Поэтому это уже не Mercurial сам по себе.

[scy]

Согласен. Монорепозиторий — это зло, в подавляющем большинстве случаев, поэтому статья скорее о том как не надо делать.
А сабмодули — это решение, идеальное для фронт + бэк, менее идеальное для ядро+кастомизация.
А когда ты файсбук проблемы твои далеки от обычных) так что не надо примерять к себе.

[ivlis]

Вот так бывает, когда из git пытаешься делать svn...

[kmmbvnr]

Мм, все так уверены что монорепозиторий зло. А гугл именно его и использует — http://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/


И вот подробное объяснение почему — http://www.infoq.com/presentations/Development-at-Google

[kmmbvnr]

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

[kohver]

Babel тоже использует monorepo, вот тут доходчиво об этом написали github.com/babel/babel/blob/master/doc/design/monorepo.md

[dfuse]

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