“git submodule init”有什么意义？

What is the point of 'git submodule init'?

提问by sampablokuper

Background

背景

To populate a repository's submodules, one typically invokes:

要填充存储库的子模块，通常调用：

git submodule init
git submodule update

In this usage, git submodule initseems to do only one thing: populate .git/configwith information that is already in .gitmodules.

在这种用法中，git submodule init似乎只做一件事：填充.git/config已经在.gitmodules.

What is the point of that?

这样做有什么意义？

Couldn't git submodule updatesimply use the information from .gitmodules? This would avoid both:

不能git submodule update简单地使用来自.gitmodules? 这将避免两者：

• an unnecessary command (git submodule init); and
• an unnecessary duplication of data (.gitmodulescontent into .git/config).

• 一个不必要的命令 ( git submodule init); 和
• 不必要的重复数据（.gitmodulescontent into .git/config）。

Question

题

Either:

任何一个：

• there are use-cases for git submodule initthat I do not know (in which case, please enlighten me!); or else
• git submodule initis cruft that could be deprecated in Git without any harm.

• 有一些git submodule init我不知道的用例（在这种情况下，请赐教！）；要不然
• git submodule init可以在 Git 中弃用而不会造成任何伤害的 cruft。

Which of these is true?

以下哪个是真的？

采纳答案by sampablokuper

Reading the git submoduledocumentation, there isa use-case that ostensibly justifies the existence of git submodule initas a standalone command.

读取git submodule文档，存在是其表面上证明存在一个用例git submodule init作为一个独立的命令。

If a user who has cloned a repository wishes to use a different URL for a submodule than is specified by the upstream repository, then that user can:

如果克隆存储库的用户希望对子模块使用与上游存储库指定的 URL 不同的 URL，则该用户可以：

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

回答by Nigiri

Imagine the repository has 10 submodules and you are interested in only two submodules of these. In such a case, you may want to get updates from only these two submodules from the remote repository from time to time. git initworks well for this, because once you execute the command git initfor these two submodules, git submodule update --remoteapplies only to them.

假设存储库有 10 个子模块，而您只对其中的两个子模块感兴趣。在这种情况下，您可能希望不时仅从远程存储库中的这两个子模块中获取更新。git init对此很有效，因为一旦您git init为这两个子模块执行命令，则git submodule update --remote仅适用于它们。

---

---

Appended two workflows demo.

附加了两个工作流演示。

Workflow1: Submodules are libraries which several projects use.

工作流程 1：子模块是多个项目使用的库。

I think this is one of the common use cases.

我认为这是常见的用例之一。

You just cloned "my-project".

您刚刚克隆了“我的项目”。

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

And the surface of its structure is like below.

其结构表面如下图所示。

The contents of .gitmodules

.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

You want to refactor the code code1.jswhich references lib1 and lib2 which means you don't need to clone and checkout lib3 and lib4. So you just run the below command.

您想重构code1.js引用 lib1 和 lib2的代码，这意味着您不需要克隆和检出 lib3 和 lib4。所以你只需运行下面的命令。

git submodule init lib1 lib2

Now let's see the contents of .git/config

现在让我们看看内容 .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".

这意味着类似于“准备从 example.com/demo 更新 lib1 和 lib2”。

At this point, lib1 and lib2 directories are empty. You can clone and checkout lib1 and lib2 with one command:

此时，lib1 和 lib2 目录为空。您可以使用一个命令克隆和检出 lib1 和 lib2：

git submodule update

Now you are able to refactor code1.jswithout import errors.

现在您可以在code1.js没有导入错误的情况下进行重构。

Submodules are just references to certain commits. So when you want to update libraries to new versions, you have to update the references. You can do it by the below command.

子模块只是对某些提交的引用。因此，当您想将库更新到新版本时，您必须更新引用。您可以通过以下命令来完成。

git submodule update --remote

Now you can see how useful it is to only initialize the submodules you need.

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

Workflow 2: Each submodule is a project and one big top project includes them.

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

I'm a fan of this.

我是这个的粉丝。

You clone "main-project".

您克隆“主项目”。

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

And the surface of its structure is like below.

其结构表面如下图所示。

You can see a directory named "shared". There is a rule in this workflow: if you want to use shared codes of main-project in your project, you have to create the project as a submodule of main-project.

您可以看到一个名为“shared”的目录。这个工作流有一个规则：如果你想在你的项目中使用主项目的共享代码，你必须将项目创建为主项目的子模块。

I like to put entity classes in shared directory like below.

我喜欢将实体类放在共享目录中，如下所示。

Back to the submodule workflow, the contents of .gitmodules is like the following.

回到子模块工作流程，.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

This time you want to refactor some code in the shared directory of the main-project and you know that only sub-project1 and sub-project2 reference shared code, which means you don't need to clone and checkout sub-project3 and sub-project4. So you just run the command below.

这次要重构main-project共享目录下的一些代码，知道只有sub-project1和sub-project2引用了共享代码，也就是说不需要clone和checkout sub-project3和sub-项目 4. 所以你只需运行下面的命令。

git submodule init sub-project1 sub-project2

And like I mentioned in workflow1, you need to run the command below to clone and checkout them.

就像我在工作流1中提到的那样，您需要运行以下命令来克隆和检出它们。

git submodule update

Would I do git submodule update --remotein this case? Or do I even have to init and update submodules to refactor code in the shared directory? Yes, because you have to run tests in submodules after refactoring the shared code and if any update of submodules is committed and pushed to the remote repository while you are refactoring, then you need to get it by git submodule update --remote.

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