真的有人在使用 git super/subprojects 吗？

Is anyone really using git super/subprojects?

提问by Makis

Is anyone using the new git super/subproject feature in real projects? How well does it work? For instance, I understand that if I push to a subproject I have to manually call superprojects hooks (maybe using the subprojects hook, but nevertheless)?

有人在实际项目中使用新的 git super/subproject 功能吗？效果如何？例如，我知道如果我推送到一个子项目，我必须手动调用 superprojects 钩子（也许使用 subprojects 钩子，但仍然如此）？

采纳答案by VonC

By using submodule, you are defining in your Git workspace (meaning your "super-project" Git repository) a configuration.
By "configuration", I mean "the list of tags or SHA-1 node necessary to work in your workspace".
(and by work, I mean whatever "development effort" you are doing within your workspace: classic compilation, or patch, or merge, or deployment, or...).
That is the case when your are cloning a super-project and "git update" your submodules: you are checkouting the exact repos SHA1 which were previously committed in the super-project (recorded as gitlinkin the index).

通过使用子模块，您将在您的 Git 工作区（即您的“超级项目”Git 存储库）中定义一个配置.
通过“配置”，我的意思是“在您的工作区中工作所需的标签列表或 SHA-1 节点”。
（我所说的工作是指您在工作区中所做的任何“开发工作”：经典编译、补丁、合并、部署，或...）。
当您克隆一个超级项目和“ git update”您的子模块时就是这种情况：您正在检出之前在超级项目中提交的确切存储库 SHA1（在索引中记录为gitlink）。

The other mode is when you are working on your super-project andon one or more submodules.
That means, for a given submodules, you have checked out a specific branch (you are no longer using a detached HEAD for the content of that submodules, but rather a pointer to the tip of a branch).
Then, "pushing a submodule" means updating a distant repository containing that sub-module (and only that one).

另一种模式是当你在你的超级项目和一个或多个子模块上工作时。
这意味着，对于给定的子模块，您已检出特定分支（您不再使用分离的 HEAD 来表示该子模块的内容，而是使用指向分支尖端的指针）。
然后，“推送子模块”意味着更新包含该子模块（并且只有那个）的远程存储库。

The actual trick in that last scenario (which could deserve a hook of you want one) is when you are pushing the super-project: you need to be sure to have pushed all your sub-modules first.

在最后一个场景中的实际技巧（可能值得你想要一个钩子）是当你推送超级项目时：你需要确保首先推送所有子模块。

From the submodule tutorial:

从子模块教程：

Always publish the submodule change before publishing the change to the superproject that references it. If you forget to publish the submodule change, others won't be able to clone the repository (of the super-project)

在将更改发布到引用它的超级项目之前，始终发布子模块更改。如果您忘记发布子模块更改，其他人将无法克隆（超级项目的）存储库

Don't forget you can configure a submodule to follow a branch.

不要忘记你可以配置一个子模块来跟随一个分支。

回答by Spider

FWIW, we are trying to make the leap to git, and our project (bitweaver, a content management system) is a highly modular system, with nearly 160 repositories). A "build" generally contains two dozen or more sub-repositories. We used 'virtual modules' in CVS, and this worked fantastically for us, however CVS has it's own limitations for staging commits.

FWIW，我们正在尝试向 git迈进，我们的项目（bitweaver，一个内容管理系统）是一个高度模块化的系统，拥有近 160 个存储库）。“构建”通常包含两打或更多子存储库。我们在 CVS 中使用了“虚拟模块”，这对我们来说非常有效，但是 CVS 有它自己的暂存提交限制。

Git submodules have some severe limitations, and you should definitely evaluate mercurial's implementation as it is a certainly more friendly and flexible for external/modular projects (ie it supports other VCS systems, even HgGit).

Git 子模块有一些严重的限制，你一定要评估 mercurial 的实现，因为它对于外部/模块化项目肯定更友好和灵活（即它支持其他 VCS 系统，甚至 HgGit）。

Here are the biggest challenges:

以下是最大的挑战：

1. Each submodule is hard linked to a particular commit when you "git submodule add" in the super-respository. This is by design, and sought as a benefit by git maintainers, so I would not expect it to change any time soon. This is painful in a system like ours where commit's are always happening in the submodules. You have to update the super project to keep up, or update your sub-repos to master after initial submodule update. (see supergit below for our solution).

2. You cannot easily commit and push to all the sub-repo's from the root. This is also very annoying, see supergit below.

3. Various gotchasthat can be excruciating, especially things that "silently overwrite changes".

1. 当您在超级存储库中“git submodule add”时，每个子模块都硬链接到特定的提交。这是设计使然，并且是 git 维护者寻求的好处，所以我不希望它很快改变。在像我们这样的系统中，这很痛苦，因为提交总是发生在子模块中。您必须更新超级项目以跟上，或者在初始子模块更新后将您的子存储库更新为 master。（有关我们的解决方案，请参阅下面的 supergit）。

2. 您不能轻松地从根提交和推送到所有子存储库。这也很烦人，见下面的supergit。

3. 各种可能令人痛苦的陷阱，尤其是“默默覆盖更改”的事情。

supergit

超级git

We've written a shell script call supergitthat handles some of the painfulness. It does the clone, submodule init, update, and checkout master all in one fell swoop. It will also perform git commands to all directories in the super-repo individually (bulk git processing of sorts).

我们编写了一个shell 脚本调用 supergit来处理一些痛苦。它一举完成了克隆、子模块初始化、更新和结帐大师的所有工作。它还将单独对超级存储库中的所有目录执行 git 命令（各种批量 git 处理）。

HTH, good luck.

HTH，祝你好运。

回答by Dustin

If you mean submodules, then certainly.

如果您的意思是子模块，那么当然可以。

The submodules don't and should not know everywhere they're used. For example, I have one submodule that is used in several projects that I know of (and quite possibly several that I don't).

子模块不知道也不应该知道他们在哪里使用。例如，我有一个子模块在我知道的几个项目中使用（很可能还有几个我不知道）。

Pushing to a submodule does not in any way affect the version of code used by the project containing the submodule, so I'm not sure what you'd want a hook to do anyway.

推送到子模块不会以任何方式影响包含子模块的项目所使用的代码版本，因此我不确定您无论如何都希望挂钩做什么。