Как мне адаптировать мою стратегию svn: externals для подмодулей git? - PullRequest
10 голосов
/ 22 октября 2010

Мне трудно понять, как изменить свое мышление на мерзавец, и столкнулся со следующей проблемой. У меня есть ситуация, когда у нас есть общий движок и несколько проектов, которые используют движок. Внутренние группы разработчиков и сторонние группы могут работать над проектами, использующими общий механизм, и хотят максимально использовать HEAD общего механизма во время разработки, всего за несколько недель до отправки, когда общий механизм будет помечен и разветвленный, и проект будет использовать эту ветвь. Проектные группы обычно работают только над одним проектом, но могут вносить изменения в общий движок во время отладки или добавления функций. Когда они фиксируют эти изменения, наша система сборки запускается, чтобы найти любые проблемы, которые они могли внести с фиксацией.

Я (думаю, я) хочу использовать эту же модель в новом проекте / новой компании. В SVN структура была примерно такая: shared_engine

project_in_dev-+
               +- svn:external shared_engine:head
project_about_to_ship-+
                      +-svn:external shared_engine_rev1_branch

Это сработало очень хорошо:

  • Разработчики проекта могут сделать одну команду, чтобы проверить все зависимости, которые им понадобятся
  • Разработчики проектов могут легко выполнять работу с движком и легко подключаться к общему движку
  • Мы могли бы легко изменить или изменить общий движок, который проект использовал с внешними и ревизиями
  • Обновления движка легко получить с помощью ежедневного «обновления из корневого проекта»

Хорошо, теперь я перешел на git, и подмодули SEEM стали новым способом работы с внешним кодом, но, похоже, я потерял некоторые функции.

  • Это многоэтапный процесс, позволяющий фактически получить все зависимости проекта. Разработчики проекта должны сделать клон git, а затем обновить подмодуль git init / git --recursive
  • Это многоэтапный процесс обновления корневого проекта и подмодуля, поэтому, если другой разработчик вносит изменения в корневой проект, соответствующие изменениям подмодуля, вы не сразу получаете соответствующий код и можете сильно запутаться.
  • Подмодуль заблокирован для определенного коммита, и если вы внесете изменения в подмодуль, у вас будут проблемы с его настройкой для работы с головкой общего механизма
  • У меня нет контроля над тем, какую версию общего движка разработчик разработал, не дав инструкции о том, что обновлять до

Итак, мои вопросы таковы:

  • Прежде всего, верны ли приведенные выше предположения о подмодулях? Кажется, это основано на том, что я прочитал, но я не уверен на 100%, так как я все еще выясняю git
  • Если мои предположения верны, я подхожу к проблеме с правильным процессом? Нужно ли корректировать свое мышление при использовании git? Другими словами, есть ли другой способ сделать то, что я пытаюсь сделать, и нужно думать о процессе по-другому?
  • Предполагая, что я не взорвал первые два, и подмодули не будут делать то, что я хочу, что будет? Я читал о слияниях поддеревьев, но они тоже не совсем верны, так как похоже, что я не могу внести изменения в общий код обратно в репозиторий.

Большое спасибо за вашу помощь и терпение. Если это не очевидно, я очень новичок в git, и мне это нравится, и я хочу принять это, но у меня все еще есть некоторые концептуальные недоразумения, потому что у меня, вероятно, был поврежден мозг за годы использования центральных репо. Я хочу учиться! Кроме того, я занимался весь день и просматривал различные посты в блогах, вопросы о стекопереработке и т. Д., И я до сих пор не понимаю, мне, очевидно, нужно, чтобы это было подробно описано в моей ситуации. У меня нет коллег по этому поводу, есть ли какие-нибудь группы пользователей в Сиэтле, где могут быть какие-то гит-гуру? :)

1 Ответ

4 голосов
/ 22 октября 2010

Вы правы, что подмодуль всегда ссылается на конкретную ревизию, которая фиксируется, когда вы git add каталог подмодуля (и, следовательно, вы можете контролировать точно , что проверено в окне разработчика).Но я рассматриваю это как особенность, поскольку вы всегда можете запросить HEAD субмодуля, когда вам это нужно.С другой стороны, это означает, что вы всегда получаете одно и то же состояние, когда извлекаете старое состояние вашего проекта, независимо от того, что изменилось в подмодулях.Вы можете думать о них как о внешних svn, которые прикреплены к определенной ревизии.

Что касается изменений в подмодуле, то это просто обычные репозитории git, где вы можете работать с обычным рабочим процессом, как если бы они были клонированыв собственную рабочую копию.Одно отличие от обычного клона состоит в том, что извлечение субмодуля, скорее всего, является отсоединенной головкой, поэтому вы должны создать ветку самостоятельно, когда вносите в нее изменения.

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

РЕДАКТИРОВАТЬ

Я нашел подробное объяснение о подмодулях: http://longair.net/blog/2010/06/02/git-submodules-explained/.

...