Подмодуль - это не что иное, как другой репозиторий Git, плюс некоторая связь, которая сохраняется в суперпроекте.
Один репозиторий Git, как правило, никогда не знает о коммитах в некоторых другихGit репозиторий. Кто-то может подумать, что связь в суперпроекте может сделать суперпроект Git более осознанным ... и иногда это может быть , но не в вашем случае. (Мы точно не знаем, каков ваш случай, но, очевидно, каким бы он ни был, он не был одним из тех редких случаев, когда суперпроект сразу замечает. ?)
Если один репозиторий Git - давайте назовемэто S для субмодуля - это клон какого-либо другого Git-репозитория (назовем его OS для Origin of Submodule), затем вы можете ввести репозиторий S и запустить git fetch origin. Это приносит любые новые коммиты из OS в S . Ни один новый коммит не получит извлеченных в S , потому что git fetch никогда не изменяет ничего, кроме имен удаленного отслеживания в репозитории. Он только подхватывает новые коммиты (затем обновляет S * orgin/master и т. Д. Как approrpriate).
Если вы сейчас, в репозитории S , запустите git checkout <em>hash-id</em> или git checkout <em>non-branch-name</em>, указанный вами коммит извлекается в S как отдельный HEAD. Если вы запускаете git checkout <em>branch-name</em>, указанный вами коммит извлекается как прикрепленный HEAD: S теперь находится на ветке. Важная часть всего этого не в том, прикреплена или отсоединена ГОЛОВА. Это то, что вы извлекли какой-то конкретный коммит . 1
Когда какой-то репозиторий Git - назовем его R - использует какой-то другой репозиторий S в качестве подмодуля, различные операции в R будут вводить подмодуль S и запускать git checkout <em>hash</em>, чтобы поместить S в отдельный HEADзаявить об одном конкретном коммите. Используемый здесь хэш-идентификатор записывается в коммитах, сделанных в R .
Если вы сами введете S и git checkout некоторые другие хэшID, затем вернитесь к R и спросите о его ( R ) статусе, обработка Git R заметит, что S больше не в коммите, который запрашивал R . Поэтому будет сказано, что что-то произошло в S . Теперь вы можете запустить git add path/to/S, чтобы обновить хеш-идентификатор в индексе R , чтобы он записывал хеш-идентификатор фиксации, выбранной вами в S . Создание нового коммита в R в этот момент запишет этот новый хэш-идентификатор в качестве правильного хэш-идентификатора.
Проверка любого конкретного коммита в R заполнит * 1090Индекс Git * R с хеш-идентификатором подмодуля из этого коммита. Если вы не укажете рекурсивную проверку, это не повлияет на идентификатор хеша, который извлекается как отдельная головка в S ;вы должны запустить git submodule update, чтобы R ввести S и выполнить соответствующую команду git checkout <em>hash</em>.
Если вы хотите выполнить собственное ручное управление S , это правильный способ сделать что-то: вы не хотите R проверять вещи в S и возиться с ручным управлением. Если вы не хотите ручное управление - если вы хотите, чтобы R всегда контролировал S - используйте режим проверки --recursive в R .
1 Хотя R обычно использует отдельную головку, суперпроект R делаетне волнует подключена ли S ГОЛОВКА. R собирается записать необработанный хеш-идентификатор фиксации, несмотря ни на что. Таким образом, он просто читает хеш-идентификатор из S , а не из-за его имени или отсутствия ветки.