Comments 28
Тут бы ещё рассказ про то, как готовить git submodules не помешал.
Спасибо, учту Ваше пожелание. Есть пара хороших статей на эту тему, обязательно до них доберусь.
Вот. Кое-какие мысли по поводу и некоторое обсуждение. Может, пригодится.
Ещё бы они начали поддерживать lfs на самом bitbucket. Уже год тикет висит а подвижек не видно.
Неправда Ваша, работа кипит.
становится неуклюжим для репозитория со многими несвязанными проектами.
Репозиторий содержит набор сервисов, фреймворков и библиотек, составляющих единое логическое приложение.
Вы уже как-то определитесь, они единое логическое приложение или таки не связаны.
BitBucket Server 4.3 уже поддерживает LFS.
Вы уже как-то определитесь, они единое логическое приложение или таки не связаны.
Думаю, это следует читать как «содержит набор сервисов, фреймворков и библиотек, написанных специально для приложения и нигде более в свободном виде не использующихся». Они вроде как и не связаны, но и по-отдельности никому не нужны.
Думаю, это следует читать как «содержит набор сервисов, фреймворков и библиотек, написанных специально для приложения и нигде более в свободном виде не использующихся». Они вроде как и не связаны, но и по-отдельности никому не нужны.
Важна даже не логическая связанность (части одного приложения). Git следит на всем деревом сразу. То есть вопрос о том, надо ли всё держать в одном репозитории или следует разбить на несколько, можно переформулировать следующим образом: есть ли смысл в том, чтобы разные части имели разные версии? Если да, то их следует поместить в отдельные репозитории, если нет — то в разные. Например, вполне можно представить случай, когда есть Сервер v.4 годовой давности и Сервис v.10, выпущенный месяц назад. Однако, если поставляется сразу цельное решение, то вполне можно и все сваливать в одну кучу.
Проблема, в общем, в том, что Git продолжают считать просто интеллектуальным rsynс'ом по типу SVN: «Я жмякаю Commit. Мои изменения улетают куда-то на сервер. После этого Вася может их забрать, а я могу не волноваться, что мой жёсткий диск сломается». Коммиты как таковые не считаются чем-то самостоятельным, скорее отражением истории. Отсюда и естественность мысли о том, что Отдел №1 может возиться в своей части репозитория, а Отдел №2 — в своей, вроде бы не должны мешать, поэтому достаточно только одного репозитория. И ветки тоже не нужны, потому что история линейна как ось времени, а ветки только всё запутывают. В то же время Git считает коммиты версиями репозитория в целом, а не его отдельных файликов или частей.
В Линуксе тоже много частей и тысячи разработчиков, но это не мешает им всем работать в одном логическом репозитории. Как им это удаётся? Просто все не коммитят сразу в master центрального репозитория.
Проблема, в общем, в том, что Git продолжают считать просто интеллектуальным rsynс'ом по типу SVN: «Я жмякаю Commit. Мои изменения улетают куда-то на сервер. После этого Вася может их забрать, а я могу не волноваться, что мой жёсткий диск сломается». Коммиты как таковые не считаются чем-то самостоятельным, скорее отражением истории. Отсюда и естественность мысли о том, что Отдел №1 может возиться в своей части репозитория, а Отдел №2 — в своей, вроде бы не должны мешать, поэтому достаточно только одного репозитория. И ветки тоже не нужны, потому что история линейна как ось времени, а ветки только всё запутывают. В то же время Git считает коммиты версиями репозитория в целом, а не его отдельных файликов или частей.
В Линуксе тоже много частей и тысячи разработчиков, но это не мешает им всем работать в одном логическом репозитории. Как им это удаётся? Просто все не коммитят сразу в master центрального репозитория.
есть ли смысл в том, чтобы разные части имели разные версии?
Здравая абстракция, запомню. Но есть ситуации когда и она может сбоить. Например мобильная версия приложения под разные платформы + сайт + расширения для броузеров. Логически можно разделить, по факту могут совместно использоваться ресурсы (картинки, шрифты). Сильно не копал в эту сторону но вроде у svn была возможность подключать один репозиторий как часть другого. В общем, на мой дилетантский взгляд — системам версионного контроля нужно нечто вроде view у баз данных. Сделал вьюху от репы, в которой только тебе нужные файлы и работаешь. Если коммиты других разрабов твое не трогают — ты о них и не знаешь. Ели кто что зацепил — делаешь pull и смотришь.
UFO just landed and posted this here
В том же Subversion мультикомпонентные проекты нормально живут в рамках одного репозитория. Нет проблем ни с размерами (при клонировании отдельной директории не копируется ни чего лишнего и разработчик может делать любой срез из исходников проекта, который посчитает нужным), ни с версионированием (грубо говоря, в каждой директории своя история).
А вот у решивших мигрировать из SVN в Git подобные вопросы возникают постоянно: и с размером, ведь Git не может не копировать весь репозиторий, и с версионированием отдельных частей, поскольку история в git не связана с файловой структурой проекта. Решение о том, чтобы ввести понятие компонентов для каких-то срезов дерева исходников, чтобы разложить проект на отдельные git репозитории, не всегда подходит. К тому же это создает новые проблемы с администрированием такой структуры.
А вот у решивших мигрировать из SVN в Git подобные вопросы возникают постоянно: и с размером, ведь Git не может не копировать весь репозиторий, и с версионированием отдельных частей, поскольку история в git не связана с файловой структурой проекта. Решение о том, чтобы ввести понятие компонентов для каких-то срезов дерева исходников, чтобы разложить проект на отдельные git репозитории, не всегда подходит. К тому же это создает новые проблемы с администрированием такой структуры.
Тут как не повернись проблема будет. Вот у нас есть проект из 8 микросервисов и число их растёт. Напрямую они друг от друга не зависят никак, только API разделяют. Либо мы всё это суём в один проект и один репозиторий и тогда имеет простоту миграции API, либо по разным репозиториям и тогда не имеем проблемы быстроразрастающегося репозитория. Но имеем целый геморрой с любым изменением в API.
Есть подозрение, что 8 — это маленькое число, и если Вам удобнее держать их вместе, то надо так и делать, пока что не опасаясь разрастания репозитория, — достаточно помнить о бинарных файлах (в смысле, что добавлять их надо аккуратно или хранить в LFS).
Проблемы, связанные с количеством файлов, коммитов и веток становятся заметными при очень больших абсолютных значениях.
Проблемы, связанные с количеством файлов, коммитов и веток становятся заметными при очень больших абсолютных значениях.
UFO just landed and posted this here
Может быть решение проблемы "монолитного репозитория" — это Mercurial?
не, тормозит еще больше гита… по крайней мере мы от него отказались недавно
Чем же тормозит когда данные хранятся инкрементально?..
Один коммит связан только со своим предком.
На моем опыте — проблем не было.
31 проект в одной папочке, каждый примерно по 45-80 *.py файлов…
Полет нормальный.
Единственный важный нюанс: на Win Mercurial лучше не ставить, мягко говоря… Два раза были проблемы с кодировками… Собственный опыт… :(
Вот хороший пост про отличия Mercurial и Git:https://habrahabr.ru/post/168675/
Один коммит связан только со своим предком.
На моем опыте — проблем не было.
31 проект в одной папочке, каждый примерно по 45-80 *.py файлов…
Полет нормальный.
Единственный важный нюанс: на Win Mercurial лучше не ставить, мягко говоря… Два раза были проблемы с кодировками… Собственный опыт… :(
Вот хороший пост про отличия Mercurial и Git:https://habrahabr.ru/post/168675/
Как упомянуто в статье, Mercurial тоже надо (было) допиливать для действительно большого репозитория. И эта доработка, на самом деле, решает лишь часть проблемы.
Согласен. Монорепозиторий — это зло, в подавляющем большинстве случаев, поэтому статья скорее о том как не надо делать.
А сабмодули — это решение, идеальное для фронт + бэк, менее идеальное для ядро+кастомизация.
А когда ты файсбук проблемы твои далеки от обычных) так что не надо примерять к себе.
А сабмодули — это решение, идеальное для фронт + бэк, менее идеальное для ядро+кастомизация.
А когда ты файсбук проблемы твои далеки от обычных) так что не надо примерять к себе.
Вот так бывает, когда из git пытаешься делать svn...
Мм, все так уверены что монорепозиторий зло. А гугл именно его и использует — http://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/
И вот подробное объяснение почему — http://www.infoq.com/presentations/Development-at-Google
И вот подробное объяснение почему — http://www.infoq.com/presentations/Development-at-Google
Упс… вот это видео более конкретно — Why Google Stores Billions of Lines of Code in a Single Repository
Babel тоже использует monorepo, вот тут доходчиво об этом написали github.com/babel/babel/blob/master/doc/design/monorepo.md
Sign up to leave a comment.
Монолитные репозитории в Git