Я чувствую, что использование подмодулей Git несколько проблематично для моего рабочего процесса разработки. Я слышал о поддереве Git и Gitslave.
Что лучше для вас, зависит от ваших потребностей, желаний и рабочего процесса. В каком-то смысле они полуизоморфны, просто некоторые из них намного проще использовать для конкретных задач, чем другие.
gitslave полезен, когда вы контролируете и разрабатываете подпроекты примерно в то же время, что и суперпроект, и, кроме того, когда вы обычно хотите пометить, разветвить, нажать, вытащить и т. д. все репозитории одновременно. Насколько я знаю, gitslave никогда не тестировался на Windows. Для этого требуется перл.
git-submodule лучше, когда вы делаете не контролировать подпроекты или, более конкретно, не хотят исправлять подпроект в определенной версии, даже если подпроект изменяется. git-submodule является стандартной частью git и поэтому будет работать в Windows.
git-subtree предоставляет интерфейс для встроенной в git стратегии слияния поддеревьев. Лучше, если вы предпочитаете иметь унифицированную историю git с одним репозиторием. В отличие от стратегии слияния поддеревьев, легче экспортировать изменения в разные деревья (каталоги) обратно в исходный проект, но это не так автоматически, как с gitslave или даже с git-submodule.
репозиторий теоретически похож на gitslave, но не так хорошо задокументирован для операций не на Android, которые Я нашел. Он в значительной степени посвящен модели разработки Google Android и изначально поддерживает только несколько команд git (хотя вы можете запускать произвольные команды), а ограниченная собственная поддержка не поддерживает, например, централизованный репозиторий для отправки и проверки ветвь кажется довольно сложной.
mr от kitenet — это то, что вы хотели бы использовать, если у вас есть несколько систем управления версиями, но в основном ограничен для суперпроектов только для git из-за подхода с наименьшим общим знаменателем. Есть способы запуска произвольных команд, но они не так хорошо интегрированы.
mr run git config ... или, возможно, (что еще хуже) о методе файла конфигурации для присвоения конкретных команд именам. Конечно, если вы знаете о некоторых функциях mr, которые не были сразу очевидны при чтении справочной страницы, я хотел бы знать об этом.
- person Seth Robertson; 12.11.2012
git/contrib. Установите в Ubuntu с помощью sudo make install install-doc prefix=/usr libexecdir=/usr/lib/git-core из исходного дерева Git (не работает с упакованным Git).
- person kynan; 23.11.2012
В настоящее время я использую подмодули для разработки, а не просто связываю сторонние библиотеки. Есть несколько способов упростить жизнь с помощью подмодулей, особенно когда они являются источником конфликтов слияния или перебазирования. Посмотрите на ls-tree, чтобы получить 2 коммита, вовлеченных в конфликт в подмодуле. Это, вероятно, самая сложная часть подмодулей для людей. На данный момент сценарии значительно упростят работу с этим. Будущие версии Git должны иметь лучшую встроенную поддержку для работы с ними.
Надеюсь это поможет.
Мы столкнулись с похожей проблемой при использовании подмодулей Git в проектах, где у нас были зависимости на разных языках. Чтобы справиться с ними, мы создали инструмент с открытым исходным кодом под названием MDLR («Модульный»), который дает вам декларативные зависимости Git с контролируемой версией с функциональностью, аналогичной подмодулям Git, но без раздражающего рабочего процесса. Вы можете установить его и управлять своими зависимостями с помощью инструкций/загрузок в репозитории GitHub
Для некоторых случаев использования мне понравился каждый из следующих двух простых подходов:
Вложенные репозитории. Если в вашем программном проекте есть механизм плагинов, где каждый плагин находится в своем собственном подкаталоге, может иметь смысл игнорировать эти каталоги плагинов и в вашей локальной файловой системе сделать так, чтобы каждый из них в собственный репозиторий git. Таким образом, все ваши файлы образуют единое дерево каталогов, но управляются в разных репозиториях git. Это не смутит git.
Репозитории для отдельных пакетов. Для программных проектов, в которых вы используете какую-либо систему управления пакетами с исходным кодом (gem/bundler, npm, pear и т. п.), имеет смысл поместить повторно используемый код в отдельные git-репозитории, затем делать из них исходные пакеты, а затем устанавливать их с помощью инструмента управления пакетами в родительский проект. Git-репозиторий вашего родительского проекта будет содержать только ссылки на необходимые пакеты и их версии, в то время как фактический код этих пакетов будет игнорироваться git, как и со всеми другими пакетами и внешними библиотеками. По сравнению с предложенными выше вложенными репозиториями, это более сложный подход, поскольку он позволяет указать, какая версия пакета должна быть установлена.
