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

GIT repository layout for server with multiple projects

提问by Paul Alexander

One of the things I like about the way I have Subversion set up is that I can have a single main repository with multiple projects. When I want to work on a project I can check out just that project. Like this

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

\main
    \ProductA
    \ProductB
    \Shared

then

然后

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

As a new user to git I want to explore a bit of best practice in the field before committing to a specific workflow. From what I've read so far, git stores everything in a single .git folder at the root of the project tree. So I could do one of two things.

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

1. Set up a separate project for each Product.
2. Set up a single massive project and store products in sub folders.

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

There are dependencies between the products, so the single massive project seems appropriate. We'll be using a server where all the developers can share their code. I've already got this working over SSH & HTTP and that part I love. However, the repositories in SVN are already many GB in size so dragging around the entire repository on each machine seems like a bad idea - especially since we're billed for excessive network bandwidth.

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

I'd imagine that the Linux kernel project repositories are equally large so there must be a proper way of handling this with Git but I just haven't figured it out yet.

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

Are there any guidelines or best practices for working with very large multi-project repositories?

是否有使用非常大的多项目存储库的指南或最佳实践？

采纳答案by VonC

The guideline is simple, in regards to Git limits:

指南很简单，关于Git 限制：

• one repo per project
• a main project with submodules.

• 每个项目一个回购
• 带有子模块的主项目。

The idea is not to store everythingin one giant git repo, but build a small repo as a main project, which will reference the right commits of other repos, each one representing a project or common component of its own.

这个想法不是将所有东西都存储在一个巨大的 git repo 中，而是构建一个小的 repo 作为主项目，它将引用其他 repos 的正确提交，每个提交代表一个项目或它自己的公共组件。

---

---

The OP Paul Alexandercomments:

该OP保罗亚历山大评论：

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??

这听起来类似于 subversion 提供的“外部”支持。
我们尝试了这个，发现不断更新外部版本中的版本引用非常麻烦，因为项目是同时开发的，相互依赖。还有别的选择吗？？

@Paul: yes, instead of updating the version from the main project, you either:

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

• develop your subprojects directly from within the main project (as explained in "True Nature of submodules"),
• or you reference in a sub-repo an origintowards the same sub-repo being developed elsewhere: from there you just have to pull from that sub-repo the changes made elsewhere.

• 直接从主项目中开发您的子项目（如“子模块的真实性质”中所述），
• 或者您在子仓库中引用了origin其他地方正在开发的同一个子仓库：从那里您只需要从该子仓库中提取其他地方所做的更改。

In both case, you have to not forget to commit the main project, to record the new configuration. No "external" property to update here. The all process is much more natural.

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

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.

老实说，这听起来真的很痛苦，任何需要开发人员每次手动做某事的东西都将成为维护的常规错误来源。
我想我会研究在超级项目中使用一些脚本来实现自动化。

I replied:

我回答：

Honestly, you may have been right... that is until latest Git release 1.7.1.
git diffand git statusboth learned to take into account submodules states even if executed from the main project.
You simply cannot miss submodule modification.

老实说，您可能是对的……直到最新的Git 版本 1.7.1。
git diff并且git status两者都学会了考虑子模块状态，即使从主项目执行也是如此。
您不能错过子模块修改。

That being said:

话虽如此：

• submodules are different from SVN externals: see "Why are git submodules incompatible with svn externals?"
• managing submodules can be tricky: see "How exactly does git submodule work?".

• 子模块与 SVN 外部模块不同：请参阅“为什么 git 子模块与 svn 外部模块不兼容？”
• 管理子模块可能很棘手：请参阅“ git submodule 究竟是如何工作的？”。

回答by Andre

GitSlave allows you to manage several independent repos as one. Each repo can be manipulated by regular git commands, while gitslave allows you to additionally run a command over all repos.

GitSlave 允许您将多个独立的存储库作为一个进行管理。每个 repo 都可以通过常规的 git 命令来操作，而 gitslave 允许你额外地对所有 repos 运行一个命令。

super-repo
+- module-a-repo
+- module-b-repo

gits clone url-super-repo
gits commit -a -m "msg"

Repo-per-project has advantages with componentization and simplified builds with tools like Maven. Repo-per-project adds protection by limiting the scope of what the developer is changing - in terms of erroneous commits of garbage.

Repo-per-project 在组件化和使用 Maven 等工具简化构建方面具有优势。Repo-per-project 通过限制开发人员正在更改的范围来增加保护 - 就垃圾的错误提交而言。