Какие есть варианты при работе с подмодулями Git, из которых сделаны коммиты? - PullRequest
Новая
       45

Какие есть варианты при работе с подмодулями Git, из которых сделаны коммиты?

6 голосов
/ 24 мая 2011

На работе мы работаем над дюжиной пакетов Java OSGi, каждый из которых имеет свой собственный репозиторий git. Все пакеты будут, в конечном счете, довольно независимы друг от друга, что оправдывает отдельные репозитории - хотя сейчас мы все еще часто модифицируем несколько из них одновременно.

Когда мы делаем релиз продукта (который состоит из всех пакетов), в каждом пакете создается новая ветвь, что немного болезненно. Таким образом, мы думали об использовании git-submodule для облегчения боли (что-то вроде git submodule foreach <cmd>).

Итак, нашей желаемой установкой будет мастер-проект Product и субмодули для каждого пакета: 

Project/
  BundleA/
  BundleB/
  BundleC/

Теперь я потратил несколько часов, читая все, что мог найти о подмодулях, и я понял, что если я изменяю вещи в BundleA, я должен зафиксировать в BundleA, нажать, затем зафиксировать изменение подмодуля в Project и нажмите еще раз.

Это явно звучит так, как будто это не то, как git-submodule был разработан для использования в первую очередь. Это против лучших методов использовать это как это? Или это звучит как случай, когда альтернатива будет предпочтительнее?

  • использование git-субмодуля голыми костями
  • с использованием существующего «git wrapper»:
  • написать свои собственные простые bash-скрипты для пакетной обработки пакетов OSGi

Любые другие предложения приветствуются.

Ответы [ 2 ]

6 голосов
/ 24 мая 2011

Если вам не нужно отслеживать, что делает подпроект в суперпроекте (жесткое связывание), тогда я рекомендую вам держаться подальше от git-субмодулей.

gitslave (http://gitslave.sf.net) по сути являетсябольшой foreach вокруг каждого из подпроектов с файлом конфигурации в суперпроекте, перечисляющем подпроекты.Есть много наворотов, которые делают его более удобным, но если ваша цель состоит в том, чтобы выполнить ту же команду в суперпроекте (необязательно) и всеподпроекты gitslave примерно так же удобны, как и вы.

Так, например, создать новую ветку в gitslave:

gits checkout -b newbr

Тогда ваш суперпроект и все подпроекты создадут новую ветвь и перейдут в нее. В общем, если вы хотите выполнить команду gits для всех членов суперпроекта, просто измените команду «git» на «gits».

2 голосов
/ 24 мая 2011

Теперь я потратил несколько часов, читая все, что я мог найти о подмодулях, и я понял, что если я изменяю вещи в BundleA, я должен зафиксировать в BundleA, нажать, затем зафиксировать изменение подмодуля в Project инажмите еще раз.

Это явно звучит так, как будто это не то, как git-submodule был разработан для использования в первую очередь.Это против лучших методов использовать это как это?

Я думаю, что это именно то, как предполагается использовать подмодули, я боюсь.Хотя, возможно, предполагается, что вы обычно фиксируете новую версию в основном проекте относительно редко, поскольку вы строго утверждаете, что эта версия подмодуля правильно работает с этой версией основного проекта.Текущий дизайн системы субмодулей довольно ограничен в том, что он может делать, так как основной проект знает только о субмодуле:

  • Какой коммит должен быть в субмодуле, хранящийся в деревевместо хэша большого двоичного объекта или дерева
  • URL-адрес по умолчанию для хранилища, которое (должно) содержать этот коммит, хранится в .gitmodules и устанавливается в конфигурации при инициализации подмодуля

... и когда вы работаете в подмодуле, это похоже на работу в автономном репозитории, независимо от того, существует ли там суперпроект или нет.

Из способов упрощения этого процесса, о которых вы упомянули, этоСтоит уточнить, что репо на самом деле не использует субмодули - это альтернативная система.Это также относится и к git-slave, который многие пользователи Stack Overflow рекомендуют.

Лично я работаю над проектом, в основном репозитории которого есть 24 подмодуля, и у нас все хорошо, только с помощью полезного скрипта.это упрощает процесс фиксации новой версии субмодуля и проверки его правильности.

Еще одна (не подмодульная) альтернатива, на которую вы, возможно, захотите посмотреть: git-subtree , не путать со стратегией объединения поддеревьев.

...