假设仓库有10个子模块，而你只对其中的两个子模块感兴趣，那么你可能需要不时地从远程仓库获取这两个子模块的更新。git init很适合这种情况，因为一旦你对这两个子模块执行了git init命令，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

您希望重构引用lib1和lib2的代码code1.js，这意味着您不需要克隆和 checkout 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

This means something like "Ready to update lib1 and lib2 from example.com/demo".
此时，lib1和lib2目录为空。您可以使用一个命令克隆和 checkout lib1和lib2：

git submodule update

现在，您可以重构code1.js，而不会出现导入错误。
子模块只是对某些提交的引用。所以当你想把库更新到新版本时，你必须更新引用。你可以通过下面的命令来完成。

git submodule update --remote

现在您可以看到只初始化所需的子模块是多么有用。

工作流程2：每个子模块都是一个项目，一个大的顶级项目包含它们。

我很喜欢这个。
您克隆"主项目"。

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

它的表面结构就像下面。

您可以看到一个名为"shared"的目录。此工作流中有一个规则：如果你想在你的项目中使用主项目的共享代码，你必须创建一个项目作为主项目的子模块。
我喜欢把实体类放在共享目录中，如下所示。

回到子模块工作流，. 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引用共享代码，这意味着您不需要克隆和 checkout sub-project3和sub-project4，因此您只需运行下面的命令。

git submodule init sub-project1 sub-project2

正如我在workflow1中提到的，您需要运行下面的命令来克隆和 checkout 它们。

git submodule update

在这种情况下，我会使用git submodule update --remote吗？或者我甚至需要初始化和更新子模块来重构共享目录中的代码吗？是的，因为在重构共享代码之后，您必须在子模块中运行测试，并且如果在重构时提交了任何子模块的更新并将其推送到远程存储库，那么您需要在git submodule update --remote之前获得它。

阅读git submoduledocumentation，有 * 是 * 一个用例，表面上证明git submodule init作为一个独立的命令存在。
如果已克隆资料档案库的用户希望对子模块使用与上游资料档案库指定的URL不同的URL，则该用户可以：

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

据我所知，这就是命令所做的&因此需要的顺序：

# - git submodule init initializes your local configuration file to track the submodules your repository uses, it just sets up the configuration so that you can use the git submodule update command to clone and update the submodules.
git submodule init
# - git submodule update --init initializes your local configuration file and clones the submodules for you, using the commit specified in the main repository.
#   note, command bellow will not pull the right branch -- even if it's in your .gitmodules file, for that you need remote. Likely because it looks at the origin (pointer to remote) in github for the available branches.
#   note, bellow pulls the submodules if you didn't specify them when cloning parent project, ref: https://youtu.be/wTGIDDg0tK8?t=119
git submodule update --init
# - The --remote option tells Git to update the submodule to the commit specified in the upstream repository, rather than the commit specified in the main repository.
#git submodule update --init --remote
git submodule update --init --recursive --remote meta-dataset