Цель подмодуля - получить конкретную версию, а не просто "самую последнюю"
Что произойдет, если последняя версия была обновлена пять минут назад до несовместимой версии?Ваш основной модуль не может использовать эту версию.Так что это не то, что делают подмодули.При использовании подмодулей вы выбираете конкретный коммит в суперпроекте.Суперпроект говорит, что в действительности: для текущей фиксации суперпроекта, используйте коммит XYZ для подмодуля lib/payment-sdk.Подмодуль Git покорно проверяет этот конкретный коммит, как указано суперпроектом git (git submodule update).
Установка ветви подмодуля не меняет вышеуказанное. См. Сноску 1 дляподробнее об использовании имени ветки.
Теперь, если вы работаете в вашем хранилище, и вы заметили, что есть новый коммит для подмодуля, и вы хотите тест это, вы можете сделать это довольно легко.Просто введите подмодуль - в конце концов, это отдельный репозиторий - и git checkout коммит, который вы хотите протестировать. 1 Подмодуль остается в этом коммите, пока вы создаете и тестируете в суперпроекте.Если все идет хорошо, , затем , в суперпроекте вы запускаете:
git add lib/payment-sdk
, чтобы сообщить суперпроекту , что при следующем коммите вы делаете, вы быкак и суперпроект для команды субмодуля использовать тот же коммит, который он использует сейчас.
Если это единственное обновление, которое вам нужно сделать для суперпроекта, теперь вы можете продолжить и зафиксировать:
git commit
В противном случае, например, если новый lib/payment-sdk требует каких-либо исправлений или обновлений для суперпроекта, внесите любые другие необходимые изменения в суперпроекте, git add также и затем git commitсделать новый коммит.
1 Вы также можете немного автоматизировать это, используя git submodule update --remote, но детали становятся довольно сложными.Лично я предпочитаю, в большинстве случаев, взять прямой контроль над каждым подмодулем, перейдя в подмодуль.Если вы do хотите использовать git submodule update --remote, , это , когда настройка ветви для субмодуля что-то значит.
На этом этапе вы должны выбрать один изтри специальных режима:
checkout: это означает переключение на коммит .Идентификатор хэша коммита для извлечения в подмодуле определяется именем ветви.
merge: это означает объединение текущего коммита с другим коммитом ,Идентификатор хэша коммита, который будет использоваться для слияния, определяется по имени ветки.
rebase: это означает, что переводит текущий коммит в другой коммит. Идентификатор хэша коммита, который будет использоваться для перебазирования, определяется именем ветки.
Во всех случаях git submodule сначала будет запускать git fetch в хранилище подмодулей, если только выподавить это с помощью --no-fetch или -N.Операция git fetch - это то, что получает новые коммиты и обновляет имя, так что заданное ранее имя ветви принимает новое значение хэш-идентификатора после git fetch. Помните, что git fetch получает новые коммиты и обновляет имена удаленного отслеживания, такие как origin/master.Этот git fetch должен выполняться в подмодуле Git, а не в суперпроекте Git: это, в конце концов, отдельные, в основном независимые репозитории Git.Таким образом, операция «все в одном» git submodule update --remote делает только следующее:
cd в подмодуль; - run
git fetch; - с использованиемИмя ветви, которое вы установили ранее (как параметр «ветви» подмодуля), чтобы выяснить хеш-идентификатор, как, возможно, обновленный с помощью
git fetch на шаге 2; - запустить вторую операцию Git- например,
git checkout - используя этот хэш-идентификатор.
Toэто вручную - так что вы можете контролировать результат, а не просто предполагать, что какая-то компьютерная программа выдала правильный ответ (т. е. 42), даже если вы не уверены, что был вопрос , - вы бысделайте те же самые шаги, но, вероятно, посмотрите, что каждый из них сделал, прежде чем переходить к следующему.