Понимание подмодуля git и "замораживание" его при конкретном хеше или хешировании

Предполагая следующую компоновку проекта: -

mainrepo_git
    |____ .git
    |____ .gitmodules
    |____ proj            <------- directory containing the code files for mainrepo
            |____ 3rdpartysourcecode <-- directory containing upstream open source code
            |      |____ .git
            |      |____ 3rdpartyfiles
            |
            |____ mainrepofilesanddirectories  

mainrepo_git содержит исходный код, за который я непосредственно несу ответственность. У меня есть доступ для чтения/записи, и я могу нажать и вытащить его непосредственно в удаленный репозиторий git, который я управляю.

Вложенный внутри mainrepo_git - это каталог, который я назвал 3rdpartysourcecode. Этот каталог 3rdpartysourcecode на самом деле является еще одним репозиторией git (также обычно называемым "подмодулем git" ), который указывает на сторонний репозиторий git с открытым исходным кодом, управляемый другими разработчиками. У меня только есть доступ к нему. Нет доступа для записи.

Есть ли способ "заморозить" конкретный хэш хэша подмодуля git в отношении фиксации, сделанной в моем основном репозитории?

Например, если я нахожусь (или вернусь) к фиксации a12ucak в моем mainrepo, мой подмодуль git также возвращается к определенной версии, которую я связываю, чтобы совершить a12ucak? И когда я переключаюсь на фиксацию b349jdsak, мой подмодуль git также возвращается к версии, которую я привязываю к b349jdsak?

Итак, мой вопрос: существует способ создать привязку между конкретным фиксацией в основном репо с соответствующим фиксацией в подмодуле git? Таким образом, когда я проверяю конкретную фиксацию в основном репозитории git, соответствующее коммитирование в подмодуле git также будет проверяться.

Ответы

Ответ 1

Замораживание - это вся суть подмодулей. Вы должны действительно прочитать учебник по этому вопросу. Вкратце, git add 3rdpartysourcecode (важная никакая конечная косая черта!), За которой следует фиксация, блокирует зафиксированный в настоящий момент субмодуль для фиксации супермодуля. Затем вы используете git submodule update для проверки этой версии.