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