windows Git 子模块混乱：如何与不熟悉 git 的开发人员一起使用 git 子模块？

Git submodule mess: how to use git submodules with developers not familiar with git?

提问by cgart

I am really frustrated about using git's submodule feature. Either I still don't get it right or it just don't work as I am expecting this. Following project situation is given:

我对使用 git 的子模块功能感到非常沮丧。要么我仍然没有做对，要么它就不能像我期望的那样工作。给出如下项目情况：

Project
  | .git
  | projsrc
  | source (submodule)
  | proj.sln

In this scenario sourceis pointing to another repository containing the common source data across all our projects. There is a lot of development happening under sourceas also under projsrc. Unfortunately Projectpoints to some commit of the source submodule and not to the actual HEAD of it. This is the usual git behaviour, as far as I got it know.

在这种情况下，源指向另一个存储库，其中包含我们所有项目的公共源数据。在source和projsrc下也有很多开发。不幸的是，Project指向源子模块的一些提交，而不是它的实际 HEAD。据我所知，这是通常的 git 行为。

I already found out that

我已经发现了

git submodule update

just get the version of submodule which was commited together with the main Project. However, I would really like to be always up-to date with the submodules development, but do not have any real clue how to do this right. Hence my question is:

只需获取与主项目一起提交的子模块的版本。但是，我真的很想始终了解子模块开发的最新情况，但没有任何真正的线索如何正确地做到这一点。因此我的问题是：

Is it possible to attach the Projectto the HEAD of the submodule, reagardless of the fact if this will break the compilation of Project or not. I just don't want to go always into the submodule directory and do git pullthere. Since I think I could loose my changes done in the submodule directory, because this is simple attached to a commit and not really to any branch or so.

是否可以将项目附加到子模块的 HEAD，不管这是否会破坏项目的编译。我只是不想总是进入子模块目录并在那里执行git pull。因为我认为我可能会丢失在子模块目录中所做的更改，因为这很简单地附加到提交上，而不是真正附加到任何分支左右。

Please consider following constraints:

请考虑以下限制：

• Developers in our group are not that familiar with all VCS around. We are used to use really huge svn repository before, without any external repo features at all.
• We are working on Windows
• A click'n'forget solution would be best, since most of project members are rather scared by using a command line interface :)

• 我们小组的开发人员对周围的所有 VCS 都不太熟悉。我们以前习惯使用非常庞大的 svn 存储库，根本没有任何外部存储库功能。
• 我们正在开发 Windows
• 最好是点击'n'forget 解决方案，因为大多数项目成员都害怕使用命令行界面 :)

回答by kan

The reason why a submodule points to a particular revision is important. If you point to a HEAD, builds will be unreproducible. I.e. if you checkout yesterday's a version of the Project, you would never know which exact version of source@HEAD was yesterday.

子模块指向特定修订版的原因很重要。如果您指向 HEAD，则构建将无法重现。即，如果您签出昨天的项目版本，您将永远不会知道昨天是哪个确切版本的 source@HEAD。

That's why it always stores particular revision sha.

这就是为什么它总是存储特定的修订版 sha。

To pull all submodules you could use Easy way pull latest of all submodules

要拉取所有子模块，您可以使用Easy way pull latest of all submodules

回答by Enze Chi

I am not good at Git and submodule. But I think some simple rules would be very helpful.

我不擅长 Git 和子模块。但我认为一些简单的规则会很有帮助。

1. Commit and push from sub-directory.
2. Go back to root of your project, check the status if you need to commit and push again.

1. 从子目录提交和推送。
2. 回到项目的根目录，检查状态是否需要提交并再次推送。

when Pull. can try to use script to bundle the "pull/submodule update" together. And only do it at the root of your project.

当拉。可以尝试使用脚本将“拉/子模块更新”捆绑在一起。并且只在你的项目的根目录下做。

回答by Vanuan

Consider this:

考虑一下：

1. source is pointing to HEAD (as you would want).
2. you make changes to source inside you Project (you commit but not push them)
3. now you have two HEADs : one in your Project's source, another in your common source.

1. source 指向 HEAD （如您所愿）。
2. 您对项目内部的源进行更改（您提交但不推送它们）
3. 现在你有两个 HEAD：一个在你的项目源中，另一个在你的公共源中。

Which one you would want to be present in your Project when you make submodule update?

当您进行子模块更新时，您希望在您的项目中出现哪一个？

The problem (and the main feature) of git in your case is that you consider commit and push as atomic operation. It isn't. Git is decentralized. There is no common HEAD. You might have multiple repositories with different HEADs.

在您的情况下，git 的问题（和主要功能）是您将提交和推送视为原子操作。不是。Git 是去中心化的。没有通用的 HEAD。您可能有多个具有不同 HEAD 的存储库。

Consider this:

考虑一下：

1. you have 3 developers (A, B and C) with a git project.
2. they all pull a project's HEAD.
3. each developer has made changes to project
4. now each of them has 3 HEADS: A HEAD, B HEAD and C HEAD.

1. 你有 3 个开发人员（A、B 和 C）有一个 git 项目。
2. 他们都拉了一个项目的HEAD。
3. 每个开发人员都对项目进行了更改
4. 现在他们每个人都有 3 个头：A 头、B 头和 C 头。

Which HEAD you consider "true" HEAD?

您认为哪个 HEAD 是“真正的”HEAD？

So, to answer your question: If you want common source submodule always be synchronized with central repository, git isn't your choice. And probably none of VCSs would help you with that.

因此，回答您的问题：如果您希望公共源子模块始终与中央存储库同步，那么 git 不是您的选择。可能没有一个 VCS 会帮助你解决这个问题。

You should treat git submodule as a thirdparty library which should be updated manually with these two steps:

您应该将 git submodule 视为第三方库，应该通过以下两个步骤手动更新：

1. Pull your submodule ("download thirdparty library")
2. Commit your project with updated submodule ("place the new version of thirdparty library to your project")

1. 拉取您的子模块（“下载第三方库”）
2. 使用更新的子模块提交您的项目（“将新版本的第三方库放入您的项目”）

If you want to make changes to submodule you should do the same in reverse order:

如果您想对子模块进行更改，您应该以相反的顺序执行相同的操作：

1. Commit your submodule ("make your changes to the thirdparty library")
2. Push your submodule ("send your changes to the thirdparty library maintainer")
3. Commit your project with updated submodule ("place the new version of thirdparty library to your project")

1. 提交您的子模块（“对第三方库进行更改”）
2. 推送您的子模块（“将您的更改发送给第三方库维护者”）
3. 使用更新的子模块提交您的项目（“将新版本的第三方库放入您的项目”）