Альтернативы подмодулям Git?
Я чувствую, что использование подмодулей Git как-то проблематично для моего рабочего процесса разработки. Я слышал о Git поддереве и Gitslave.
- Существуют ли еще инструменты для проектов с несколькими хранилищами и как они сравниваются?
- Могут ли эти инструменты работать в Windows?
3 ответа
Что лучше для вас, зависит от ваших потребностей, желаний и рабочего процесса. Они в некотором смысле полуизоморфны, просто некоторые из них намного проще в использовании, чем другие для конкретных задач.
gitslave полезен, когда вы управляете подпроектами и разрабатываете их более или менее одновременно с суперпроектом, а также, когда вы обычно хотите пометить, разветвить, протолкнуть, вытянуть и т. д. все хранилища одновременно. Гицлав никогда не был проверен на окнах, о которых я знаю. Требуется Perl.
Git-submodule лучше, когда вы не управляете подпроектами или, более конкретно, хотите исправить подпроект в определенной ревизии, даже если подпроект изменяется. git-submodule является стандартной частью git и поэтому будет работать на windows.
git-subtree предоставляет интерфейс для стратегии слияния встроенных в git поддеревьев. Лучше, когда вы предпочитаете иметь "единую" историю Git с одним хранилищем. В отличие от стратегии слияния поддеревьев, проще экспортировать изменения в разные (каталоги) деревья обратно в исходный проект, но это не так автоматически, как с gitslave или даже с git-submodule.
Теоретически репо похоже на gitslave, но не так хорошо документировано для операций без андроида, которые я обнаружил. Он полностью посвящен модели разработки Google Android и только изначально поддерживает несколько команд git (хотя вы можете выполнять произвольные команды), а ограниченная встроенная поддержка не поддерживает, например, централизованный репозиторий для отправки и извлечения ветка кажется довольно сложной.
mr kitenet - это то, что вы хотели бы использовать, если у вас есть несколько систем контроля версий, но в большинстве случаев оно ограничено для суперпроектов git-only из-за подхода с наименьшим общим знаменателем. Есть способы запуска произвольных команд, но они не так хорошо интегрированы.
В некоторых случаях мне понравился каждый из следующих двух простых подходов:
Вложенные репозитории. Если в вашем программном проекте есть механизм подключаемых модулей, при этом каждый подключаемый модуль находится в своем собственном подкаталоге, имеет смысл игнорировать эти подкаталоги с помощью git и, в вашей локальной файловой системе, поместить каждый из них в свой собственный репозиторий git. Таким образом, все ваши файлы образуют единое дерево каталогов, но управляются в разных репозиториях git. Это не запутает git.
Репозитории пакетов. Для программных проектов, в которых вы используете какую-то систему управления пакетами исходного кода (gem / bundler, npm, pear и т.п.), может иметь смысл поместить повторно используемый код в отдельные репозитории git, а затем сделать из них исходные пакеты, а затем установить их с помощью инструмента управления пакетами в родительский проект. Репозиторий git вашего родительского проекта будет содержать только ссылку на необходимые пакеты и их версии, в то время как фактический код этих пакетов будет игнорироваться git, как и все остальные пакеты и внешние библиотеки. По сравнению с предложенными выше вложенными репозиториями это более сложный подход, поскольку он позволяет указать, какая версия пакета должна быть установлена.
В настоящее время я использую субмодули для разработки, а не просто для связи сторонних библиотек. Есть несколько способов облегчить жизнь с помощью подмодулей, особенно когда они являются источником конфликтов слияния или перебазирования. Посмотрите на ls-tree, чтобы получить 2 коммита, вовлеченные в конфликт в подмодуле. Это, пожалуй, самая сложная часть подмодулей для людей. На данный момент сценарии значительно облегчат работу. Будущие версии Git должны иметь лучшую встроенную поддержку для работы с ними.
Надеюсь это поможет.
Новое дополнение к списку альтернатив - Git X-Modules. Это сделано для того, чтобы избежать типичных недостатков подмодулей Git, описанных здесь. Основное отличие состоит в том, что вся синхронизация выполняется на стороне сервера, поэтому для конечных пользователей есть только обычный репозиторий Git, который они клонируют и отправляют.
Мы столкнулись с подобной проблемой при использовании подмодулей Git в проектах, где у нас были зависимости на разных языках. Чтобы справиться с ними, мы создали и с открытым исходным кодом инструмент под названием MDLR ("Модульный"), который дает вам декларативные зависимые от версии зависимости Git с функциональностью, аналогичной подмодулям Git, но без раздражающего рабочего процесса. Вы можете установить его и управлять своими зависимостями с помощью инструкций / загрузок в репозитории GitHub