В чем смысл "git subodule init"?

Фон

Чтобы заполнить подмодули репозитория, обычно вызывается:

git submodule init
git submodule update

В этом использовании git submodule init похоже, делает только одно: .git/config с информацией, которая уже находится в .gitmodules.

В чем смысл этого?

Не удалось git submodule update просто использовать информацию из .gitmodules? Это позволит избежать обоих:

ненужная команда (git submodule init); а также
ненужное дублирование данных (содержимое .gitmodules в .git/config).

Вопрос

Или:

есть прецеденты для git submodule init которые я не знаю (в этом случае, пожалуйста, просветите меня!); или иначе
git submodule init subodule git submodule init является жестким, что может быть устаревшим в Git без какого-либо вреда.

Какое из них верно?

Ответ 1

Читая документацию по git submodule, есть сценарий использования, который якобы оправдывает существование git submodule init как отдельной команды.

Если пользователь, который клонировал репозиторий, хочет использовать для подмодуля другой URL-адрес, чем тот, который указан в вышестоящем репозитории, то этот пользователь может:

git submodule init
vim .git/config # Alter submodule URL as desired, without changing .gitmodules
                # or polluting history.
git submodule update

Ответ 2

Представьте, что в репозитории 10 подмодулей, и вас интересуют только два из них. В таком случае вы можете время от времени получать обновления только от этих двух подмодулей из удаленного хранилища. Для этого хорошо работает git init, поскольку после выполнения команды git init для этих двух git submodule update --remote подмодуля git submodule update --remote применяется только к ним.

Добавлены два рабочих процесса демо.

Рабочий процесс 1: Подмодули - это библиотеки, которые используют несколько проектов.

Я думаю, что это один из распространенных вариантов использования.

Вы только что клонировали "мой проект".

git clone https://example.com/demo/my-project

И поверхность его структуры, как показано ниже.

Содержание .gitmodules

[submodule "lib1"]
    path = lib1
    url = https://example.com/demo/lib1
[submodule "lib2"]
    path = lib2
    url = https://example.com/demo/lib2
[submodule "lib3"]
    path = lib3
    url = https://example.com/demo/lib3
[submodule "lib4"]
    path = lib4
    url = https://example.com/demo/lib4

Вы хотите code1.js код code1.js который ссылается на lib1 и lib2, что означает, что вам не нужно клонировать и извлекать lib3 и lib4. Итак, вы просто запускаете команду ниже.

git submodule init lib1 lib2

Теперь давайте посмотрим содержимое .git/config

...
[submodule "lib1"]
    active = true
    url = https://example.com/demo/lib1
[submodule "lib2"]
    active = true
    url = https://example.com/demo/lib2

Это означает что-то вроде "Готовы обновить lib1 и lib2 с example.com/demo".

На данный момент каталоги lib1 и lib2 пусты. Вы можете клонировать и извлекать lib1 и lib2 с помощью одной команды:

git submodule update

Теперь вы можете выполнить рефакторинг code1.js без ошибок импорта.

Подмодули - это просто ссылки на определенные коммиты. Поэтому, когда вы хотите обновить библиотеки до новых версий, вы должны обновить ссылки. Вы можете сделать это с помощью приведенной ниже команды.

git submodule update --remote

Теперь вы можете видеть, насколько полезно инициализировать только те подмодули, которые вам нужны.

Рабочий процесс 2: каждый подмодуль является проектом, и один проект с большой вершиной включает их.

Я фанат этого.

Вы клонируете "главный проект".

git clone https://example.com/demo/main-project

И поверхность его структуры, как показано ниже.

Вы можете увидеть каталог с именем "общий доступ". В этом рабочем процессе есть правило: если вы хотите использовать общие коды основного проекта в своем проекте, вы должны создать проект как подмодуль основного проекта.

Мне нравится помещать классы сущностей в общий каталог, как показано ниже.

Возвращаясь к рабочему процессу субмодуля, содержимое .gitmodules похоже на следующее.

[submodule "sub-project1"]
    path = sub-project1
    url = https://example.com/demo/sub-project1
[submodule "sub-project2"]
    path = sub-project2
    url = https://example.com/demo/sub-project2
[submodule "sub-project3"]
    path = sub-project3
    url = https://example.com/demo/sub-project3
[submodule "sub-project4"]
    path = sub-project4
    url = https://example.com/demo/sub-project4

На этот раз вы хотите провести рефакторинг некоторого кода в общем каталоге основного проекта, и вы знаете, что только sub-project1 и sub-project2 ссылаются на общий код, что означает, что вам не нужно клонировать и извлекать sub-project3 и sub-project проекта4. Итак, вы просто запускаете команду ниже.

git submodule init sub-project1 sub-project2

И, как я упоминал в workflow1, вам нужно запустить команду ниже, чтобы клонировать и оформить их.

git submodule update

Буду ли я в этом случае git submodule update --remote? Или мне даже нужно инициализировать и обновить субмодули для рефакторинга кода в общем каталоге? Да, поскольку вы должны запускать тесты в подмодулях после рефакторинга общего кода, и если какое-либо обновление субмодулей git submodule update --remote в удаленный репозиторий во время рефакторинга, вам необходимо получить его путем git submodule update --remote.