Обновление подмодуля мерзавца

Эта страница GitPro красиво подытоживает последствия обновления субмодуля git'а

Когда вы запускаете обновление субмодуля git'а, оно проверяет конкретную версию проекта, но не внутри ветки. Это называется отсоединённой головой - это означает, что файл HEAD указывает непосредственно на коммит, а не на символическую ссылку.
Проблема в том, что вы обычно не хотите работать в окружении отсоединённой головы, потому что легко потерять изменения.
. Если вы выполните начальное обновление подмодуля, зафиксируете его в каталоге подмодуля без создания ветки для работы, а затем снова запустите обновление подмодуля git'а из суперпроекта без фиксации, Git перезапишет ваши изменения, не сообщая вам об этом. Технически вы не потеряете работу, но на неё не будет указывать ветка, так что получить её будет несколько сложно.

Примечание Март 2013:

Как упоминалось в "git-подмодуль, отслеживающий последнюю версию", теперь (git1.8.2) может отслеживать ветку.

# add submodule to track master branch
git submodule add -b master [URL to Git repo];

# update your submodule
git submodule update --remote 
# or (with rebase)
git submodule update --rebase --remote

См. "обновление субмодуля git'а --remote vs git pull".

Ответ MindTooth иллюстрирует ручное обновление (без локальной конфигурации):

git submodule -q foreach git pull -q origin master

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

ПРЕДУПРЕЖДЕНИЕ (из Учебника по субмодулям Git'а): Всегда публикуйте (push) изменение субмодуля перед публикацией (push) изменения в суперпроекте, на который оно ссылается. Если вы забудете опубликовать изменение подмодуля, другие не смогут клонировать репозиторий.

как я могу продвинуть упомянутый коммит субмодуля с скажем (помечен) 1.0 до 1.1 (даже если глава оригинального репо уже в 2.0)

Страница "Понимание субмодулей" может помочь

Субмодули Git'а реализованы с использованием двух подвижных частей:

• файл .gitmodules и
• специальный вид древовидного объекта. Вместе они триангулируют конкретную ревизию определённого репозитория, которая извлекается в определённое место в вашем проекте.

  ---

  Со страницы субмодуля git'а

  вы не можете модифицировать содержимое субмодуля из основного проекта

  100% верно: вы не можете модифицировать субмодуль, а только ссылаетесь на одну из его коммитов.

  Вот почему, когда вы модифицируете подмодуль из основного проекта, вы это делаете:

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

  Субмодуль позволяет вам иметь компонентный подход к разработке , где основной проект ссылается только на специфические коммиты других компонентов (здесь "другие репозитории Git'а, объявленные субмодулями").

  Субмодуль - это маркер (коммит) на другой Git-репозиторий, не связанный с основным циклом разработки проекта: он ("другой" Git-репозиторий) может развиваться самостоятельно.
  . Главный проект должен выбрать из этого другого репо любой коммит, который ему нужен. Однако, если вы захотите из соображений удобства модифицировать один из этих субмодулей прямо из вашего основного проекта, Git позволит вам это сделать, при условии, что вы сначала опубликуете эти модификации субмодуля в своём первоначальном Git-репо, а затем зафиксируете ваш основной проект, делая ссылку на новую версию указанного субмодуля.

  Но основная идея остаётся: ссылаться на конкретные компоненты, которые:

  • имеют свой собственный жизненный цикл
  • имеют свой собственный набор тегов
  • имеют свои собственные разработки

  Список конкретных коммитов, на которые вы ссылаетесь в вашем основном проекте, определяет вашу конфигурацию (вот что такое Configuration Management, включающая простую систему контроля версий )

  Если компонент действительно может быть разработан одновременно с вашим основным проектом (потому что любая модификация в основном проекте будет включать в себя изменение поддиректории, и наоборот), то это будет уже не "субмодуль", а слияние поддеревьев (также представленное в вопросе Передача унаследованной кодовой базы из cvs в распределённый репозиторий ), связывающее историю двух Git-репо вместе. Помогает ли это понять истинную природу субмодулей Git'а?

  .