В git
среде, где мы модульно структурировали большинство проектов, мы сталкиваемся с одним проектом на репозиторий или несколькими проектами на проектирование репозитория . Давайте рассмотрим модульный проект:
myProject/
+-- gui
+-- core
+-- api
+-- implA
+-- implB
Сегодня у нас есть один проект на репозиторий . Это дает свободу
release
отдельные компонентыtag
отдельные компоненты
Но это также неудобно для branch
компонентов, так как часто для ветвления api
требуются эквивалентные ветви core
и, возможно, другие компоненты.
Учитывая, что мы хотим использовать release
отдельные компоненты, мы все же можем получить аналогичную гибкость, используя несколько проектов для каждого проекта хранилища .
Какой опыт есть и как / почему вы решили эти проблемы?
java
programming-practices
version-control
git
maven
Йохан Шёберг
источник
источник
git-describe
.Ответы:
Есть три основных недостатка
one project per repository
, как вы описали выше. Это менее верно, если они действительно разные проекты, но, судя по звукам, изменения одного часто требуют изменений другого, что действительно может усугубить эти проблемы:git bisect
становятся намного сложнее в использовании, когда вы разбиваете свой репозиторий на суб-репозитории. Это возможно, просто это не так просто, а значит, охота на багов во времена кризиса намного сложнее.git log
просто, не выводят историю так же осмысленно со сломанными структурами хранилища. Вы можете получить полезный вывод с помощью подмодулей или поддеревьев, или с помощью других скриптовых методов, но это не то же самое, что печататьtig --grep=<caseID>
илиgit log --grep=<caseID>
сканировать все коммиты, которые вас интересуют. Вашу историю становится сложнее понять, что делает ее менее полезной, когда она вам действительно нужна.В конце концов, это расчет альтернативной стоимости. У одного бывшего работодателя наше основное приложение было разделено на 35 различных подпозиториев. Вдобавок к этому мы использовали сложный набор сценариев для поиска в истории, чтобы убедиться, что состояние (т.е. ветви производства и разработки) были одинаковыми во всех них, и развернуть их по отдельности или в массовом порядке.
Это было просто слишком много; слишком много для нас, по крайней мере. Затраты на управление сделали наши функции менее гибкими, значительно усложнили развертывание, заставили обучение новых разработчиков занимать слишком много времени, и к концу этого времени мы едва могли вспомнить, почему мы изначально сломали хранилище. В один прекрасный весенний день я потратил 10 долларов на полдень времени кластерных вычислений в EC2. Я сплел репо вместе с парой дюжин
git filter-branch
звонков. Мы никогда не оглядывались назад.источник
Кристофер очень хорошо перечислил недостатки модели «один проект на репозиторий». Я хотел бы обсудить некоторые причины, по которым вы могли бы рассмотреть подход с несколькими хранилищами. Во многих средах, в которых я работал, подход с несколькими репозиториями был разумным решением, но решение о том, сколько репозиториев иметь и где делать сокращения, не всегда было легко сделать.
На моей нынешней должности я перенес гигантский CVS-репозиторий с одним репозиторием с более чем десятилетней историей в ряд git-репозиториев. После этого первоначального решения количество хранилищ выросло (благодаря действиям других команд), и я подозреваю, что у нас их больше, чем было бы оптимальным. Некоторые новички предложили объединить репозитории, но я выступил против этого. Проект Wayland имеет аналогичный опыт. В одном из выступлений, которые я видел недавно, у них было более 200 репозиториев git, за которые ведущий извинился. Глядя на их сайт , я вижу, что сейчас они на 5, что кажется разумным. Важно отметить, что объединение и разделение репозиториев - это управляемая задача, и с ней можно экспериментировать (в пределах разумного).
Так когда же вы захотите несколько хранилищ?
Точки 2 и 3 имеют значение только в том случае, если точка 1 верна. Разделив наши репозитории, я значительно сократил задержки, с которыми сталкиваются наши сторонние коллеги, уменьшил потребление диска и улучшил сетевой трафик.
4 и 5 более тонкие. Когда вы разделяете репозитории, скажем, клиент и сервер, это делает более дорогостоящим координацию изменений между кодом клиента и сервера. Это может быть позитивным, поскольку поощряет разделение интерфейса между ними.
Даже с недостатками проектов с несколькими хранилищами, таким образом проделана большая респектабельная работа - на ум приходят Wayland и Boost. Я не верю, что консенсус относительно лучших практик еще не выработан, и требуется определенное суждение. Инструменты для работы с несколькими репозиториями (git-subtree, git-submodule и другие) все еще находятся в стадии разработки и экспериментов. Мой совет - экспериментировать и быть прагматичным.
источник
Поскольку мы используем GitHub, у нас фактически есть несколько проектов в одном репо, но мы гарантируем, что эти проекты / модули должным образом модулированы (мы используем соглашения -api и -core + Maven + статическая проверка и проверка во время выполнения и даже могли бы однажды перейти на OSGi для загрузки) ,
На чем это экономит? Что ж, нам не нужно выдавать несколько запросов на извлечение, если мы меняем что-то маленькое в нескольких проектах. Вопросы и вики хранятся централизованно и т. Д.
Мы по-прежнему рассматриваем каждый модуль / проект как самостоятельный независимый проект, а также строим и интегрируем их отдельно в наш CI-сервер и т. Д.
источник
submodules
или выпускаете / помечаете весь репозиторий?git log -1 -- <project_dir>
). Это действительно здорово. Этот ответ заслуживает большего количества голосов.Для меня основным отличием в использовании одного или нескольких репозиториев являются ответы на следующие вопросы:
Например, у меня есть небольшое приложение (только клиент), которое проверяет «качество» хранилища Subversion. Существует базовая реализация, которую можно запустить из командной строки, и она хорошо работает с Java 6. Но я начал реализовывать пользовательский интерфейс, который использует JavaFX как часть Java 8. Поэтому я разделил 2 и создал второй репозиторий (со вторым процессом сборки), с другим расписанием, ...
Мне нравятся ответы выше (проголосовал за них), но я думаю, что они не вся правдивая история. Поэтому я хотел бы добавить аргументы для разделения репозиториев. Таким образом, реальный ответ (когда разделить) может быть где-то посередине ...
источник
Возможно , вам подойдет git-subtree (см. Блог Atlassian , средний блог или ссылка на ядро ). Таким образом, каждый ваш проект верхнего уровня будет использовать набор поддеревьев, возможно, разных версий.
источник
Исходя из вашего примера, хранилища должны быть настроены с точки зрения их взаимозависимости. Все рассуждения о разработке MicroServices и Domain Driven Design применимы здесь: в некоторых случаях допускается дублирование кода, работа с интерфейсами, не нарушайте совместимость, если это не требуется, и т. Д.
Теперь, на мой взгляд, пользовательский интерфейс должен быть независимым от серверной части. Таким образом, репозиторий проекта пользовательского интерфейса обычно должен содержать код пользовательского интерфейса и контроллер клиента. Клиентский контроллер будет соединяться с сервисными контроллерами абстрактно. Они будут использовать сервисную абстракцию client / api, которая имеет версии отдельно от сервиса, так что сервис может быть обновлен, не нарушая клиент (ы) (может быть несколько разных клиентов).
Таким образом, сама служба должна быть собственным хранилищем. На мой взгляд, сервис - это просто оболочка для бизнес-логики, основанной на единой сути. Таким образом, бизнес-логика обычно должна быть отделена от сервисной технологии, которая ее размещает. С другой стороны, реализация репозитория обычно настолько тесно связана с бизнес-логикой, что может быть интегрирована в тот же репозиторий. Но даже там ваш пробег может варьироваться.
Конечно, простые проекты, которые вряд ли сильно изменятся с точки зрения технологии или поддержки нескольких стеков, где весь пользовательский интерфейс может быть размещен из того же источника, что и бэкэнд, а бэкэнд-сервисы обычно используются только одним и тем же клиентом, могут получить больше преимуществ тесно интегрированные репозитории.
В этом случае вам, вероятно, будет достаточно иметь полную вертикаль в одном репозитории и сосредоточиться на том, чтобы убедиться, что ваши функциональные домены должным образом автономны в своем собственном репозитории. Тогда у вас все еще есть большинство преимуществ меньших репозиториев, и, в противном случае, небольшие накладные расходы.
источник