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

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

если кому-то нравится мой ответ, пожалуйста, поправьте мои ошибки в Английский.

добавлена демонстрация двух рабочих процессов.

Workflow1: подмодули-это библиотеки, которые используют несколько проектов.

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

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

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 который ссылается на 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

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

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

я поклонник этого.

вы клонируете "main-project".

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

и поверхность своей структуры подобна ниже.

вы можете увидеть каталог с именем "shared". В этом рабочем процессе есть правило: если вы хотите использовать общие коды main-project в своем проекте, вы должны создать проект как подмодуль 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

на этот раз вы хотите, чтобы отрефакторить код в общий справочник главного-проекта и вы знаете, что только суб-project1 и суб-проект2 ссылка общий код, который означает, что вам не нужно клонировать и проверка суб-project3 и суб-project4. Поэтому вы просто запустите команду ниже.

git submodule init sub-project1 sub-project2

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

git submodule update

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

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