Эта страница GitPro действительно суммирует последствия обновления подмодуля git
Когда вы запускаете git submodule update, он проверяет конкретную версию проекта, но не внутри ветви. Это называется наличием отдельной главы - это означает, что файл 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 submodule update --remoteпротивgit pull ".
MindTooth «сек ответ иллюстрирует обновление вручную (без локальной конфигурации):
git submodule -q foreach git pull -q origin master
В обоих случаях это изменит ссылки на подмодули ( gitlink , специальная запись в индексе родительского репо ), и вам нужно будет добавить, зафиксировать и отправить указанные ссылки из основного репо.
В следующий раз, когда вы будете клонировать это родительское репо, оно заполнит подмодули, чтобы отразить эти новые ссылки SHA1.
В остальной части этого ответа подробно описывается классическая функция субмодуля (ссылка на фиксированный коммит, который является основным понятием понятия подмодуля).
Чтобы избежать этой проблемы, создайте ветку, когда вы работаете в подмодульном каталоге с git checkout -b work или чем-то аналогичным. Когда вы обновите субмодуль во второй раз, он все равно вернет вашу работу, но, по крайней мере, у вас есть указатель для возврата.
Переключение веток с подмодулями в них также может быть сложным. Если вы создаете новую ветвь, добавляете туда подмодуль и затем переключаетесь обратно на ветку без этого подмодуля, у вас все еще остается каталог подмодуля в качестве неотслеживаемого каталога:
Итак, чтобы ответить на ваши вопросы:
могу ли я создавать ветки / модификации и использовать push / pull так же, как я бы делал это в обычных репозиториях, или есть вещи, которые нужно соблюдать осторожность?
Вы можете создать ветку и нажать на изменения.
ПРЕДУПРЕЖДЕНИЕ (из учебника по Git Submodule ): всегда публиковать (отправлять) изменения подмодуля, прежде чем публиковать (отправлять) изменения в суперпроект, который ссылается на него. Если вы забудете опубликовать изменение субмодуля, другие не смогут клонировать репозиторий.
как бы я продвинул коммит субмодуля, на который ссылаются, с say (tagged) от 1.0 до 1.1 (даже если голова исходного репо уже на 2.0)
Страница « Понимание подмодулей » может помочь
Подмодули Git реализованы с использованием двух движущихся частей:
.gitmodulesфайл и- особый вид дерева.
Вместе они триангулируют конкретную ревизию определенного репозитория, которая извлекается в определенное место в вашем проекте.
Со страницы подмодуля git
вы не можете изменять содержимое подмодуля из основного проекта
100% правильно: вы не можете изменить подмодуль, а только сослаться на один из его коммитов.
Вот почему, когда вы изменяете подмодуль из основного проекта, вы:
- необходимо зафиксировать и передать в подмодуле (в модуль восходящего потока), и
- затем перейдите в ваш основной проект и повторите коммит (для того, чтобы этот основной проект ссылался на новый коммит подмодуля, который вы только что создали и отправили)
Подмодуль позволяет вам разрабатывать компонентный подход , когда основной проект ссылается только на конкретные коммиты других компонентов (здесь «другие репозитории Git, объявленные как субмодули»).
Подмодуль - это маркер (коммит) в другом репозитории Git, который не связан основным циклом разработки проекта: он («другое» репозиторий Git) может развиваться независимо.
Основной проект должен выбрать из этого репо то, что ему нужно.
Однако, если вы хотите, из-за удобства , изменить один из этих подмодулей непосредственно из вашего основного проекта, Git позволяет вам сделать это, при условии, что вы сначала опубликуете эти изменения подмодуля в его исходном репозитории Git, а затем подтвердите свой основной проект, ссылаясь на новая версия указанного субмодуля.
Но основная идея остается: ссылки на конкретные компоненты, которые:
- имеют свой жизненный цикл
- иметь свой собственный набор тегов
- имеют собственное развитие
Список конкретных коммитов, на которые вы ссылаетесь в своем основном проекте, определяет вашу конфигурацию (это то, чем занимается Configuration Management, включая простую систему контроля версий )
Если компонент действительно может быть разработан в то же время, что и ваш основной проект (поскольку любая модификация основного проекта будет включать изменение подкаталога и наоборот), то это будет не «подмодуль», а скорее слияние поддеревьев (также представлено в вопросе « Перенос базы устаревшего кода из cvs в распределенный репозиторий» ), связывающее историю двух репозиториев Git вместе.
Помогает ли это понять истинную природу подмодулей Git?