具有多个项目的服务器的 GIT 存储库布局

Question

我喜欢我设置 Subversion 的方式之一是我可以拥有一个包含多个项目的主存储库。当我想处理一个项目时，我可以只检查那个项目。像这样

\main
    \ProductA
    \ProductB
    \Shared

然后

svn checkout http://.../main/ProductA

作为 git 的新用户，我想在致力于特定工作流程之前探索该领域的一些最佳实践。从我目前所读到的内容来看，git 将所有内容都存储在项目树根目录下的单个 .git 文件夹中。所以我可以做两件事中的一件。

1. 为每个产品设置一个单独的项目。
2. 设置一个大型项目并将产品存储在子文件夹中。

产品之间存在依赖关系，因此单个庞大的项目似乎是合适的。我们将使用一个服务器，所有开发人员都可以在其中共享他们的代码。我已经通过 SSH 和 HTTP 以及我喜欢的那部分工作了。然而，SVN 中的存储库已经有好几 GB 的大小，因此在每台机器上拖拽整个存储库似乎不是一个好主意 - 特别是因为我们要为过多的网络带宽付费。

我想 Linux 内核项目存储库同样大，因此必须有一种使用 Git 处理此问题的正确方法，但我还没有弄清楚。

对于处理超大型多项目存储库，是否有任何指南或最佳实践？

Answer 1

指南很简单，关于 Git limits :

• 每个项目一个 repo
• submodules 的主要项目。

我们的想法不是将一切存储在一个巨大的 git 仓库中，而是构建一个小型仓库作为主项目，它将引用其他仓库的正确提交，每个仓库代表一个项目或公共(public)项目其自身的组成部分。

---

OP Paul Alexander comments:

This sounds similar to the "externals" support provided by subversion.
We tried this and found it extremely cumbersome to constantly update the version references in the externals since the projects are developed concurrently with dependencies on each other. Is there another option??

@Paul:是的，不是从主项目更新版本，而是:

• 直接从主项目中开发子项目(如“True Nature of submodules”中所述)，
• 或者您在子仓库中引用一个 origin 指向正在其他地方开发的同一个子仓库:从那里您只需要从该子仓库中提取在其他地方所做的更改。

在这两种情况下，您都不要忘记提交主项目，以记录新配置。此处没有要更新的“外部”属性。整个过程更加自然。

Honestly, this sounds like a real pain and anything that requires developers to do something manually each time is just going to be a regular source of bugs an maintenance.
I suppose I'll look into automating this with some scripts in the super project.

我回复:

老实说，你可能是对的......直到最新的 Git release 1.7.1 。
git diff 和 git status 都学会了考虑子模块状态，即使从主项目执行也是如此。
您绝对不能错过子模块修改。

话虽这么说:

• 子模块不同于 SVN 外部:参见“Why are git submodules incompatible with svn externals?”
• 管理子模块可能很棘手:请参阅“How exactly does git submodule work?”。