具有多个项目的服务器的GIT存储库布局
我喜欢Subversion设置的方式之一是可以有一个包含多个项目的主存储库。 当我想在一个项目上工作时，我可以检查一下这个项目。 喜欢这个
\main \ProductA \ProductB \Shared 然后
svn checkout http://.../main/ProductA
作为git的新用户，我希望在提交特定的工作stream程之前，在现场探索一些最佳实践。 从我读到目前为止，git将所有内容都存储在项目树根目录下的单个.git文件夹中。 所以我可以做两件事之一。
- 为每个产品设置一个单独的项目。
- 设置一个大型项目并将产品存储在子文件夹中。
产品之间有依赖关系，所以这个单一的大型项目似乎是合适的。 我们将使用一个服务器，所有开发人员可以共享他们的代码。 我已经通过SSH和HTTP进行了这个工作，而我喜欢这个部分。 但是，SVN中的存储库已经有很多GB，所以在每台计算机上拖放整个存储库似乎都是一个糟糕的主意 – 尤其是因为我们要花费过多的networking带宽。
我可以想象，Linux内核项目库同样大，所以必须有一个适当的方式来处理这个与Git，但我还没有想出来。
是否有任何指导方针或最佳做法与非常大的多项目存储库工作？
准则很简单，就Git的限制而言 ：
- 每个项目一个回购
- 一个子模块的主要项目。
这个想法并不是把所有东西都存放在一个巨大的git仓库中，而是build立一个小型仓库作为主要项目，它将参考其他仓库的正确提交，每个仓库都代表一个项目或者自己的共同组件。
OP保罗亚历山大 评论说 ：
这听起来类似于颠覆提供的“外部”支持。
我们试过这个，发现在外部不断更新版本引用是非常麻烦的，因为项目是在相互依赖的基础上同时开发的。 有另外的select吗？
@Paul：是的，而不是从主项目更新版本，您可以：
- 直接从主项目内开发子项目（如“ 子模块的真实性 ”所述）
- 或者你在一个子回购仓库中引用一个
origin向着其他地方正在开发的同一个子回购仓库：从那里你只需从这个子回购仓库中取消其他地方所做的改变。
在这两种情况下，您都不得不提交主项目，以logging新的configuration。 没有“外部”属性更新在这里。 整个过程更自然。
老实说，这听起来像一个真正的痛苦，任何需要开发人员每次手动做一些事情，只是将成为一个错误维护的常规来源。
我想我会考虑用超级项目中的一些脚本来自动化这个。
我回答：
老实说，你可能是对的…直到最新的Git版本1.7.1 。
即使从主项目执行， git diff和git status都学会了考虑子模块的状态。
你根本不能错过子模块修改。
话虽如此：
- 子模块不同于SVN外部：请参阅“ 为什么git子模块与svn外部不兼容？ ”
- pipe理子模块可能会非常棘手：请参阅“ git子模块的工作原理？ ”。
GitSlave允许您作为一个pipe理几个独立的回购。 每个回购可以由普通的git命令操纵，而gitslave允许你额外运行一个命令，所有回购。
super-repo +- module-a-repo +- module-b-repo gits clone url-super-repo gits commit -a -m "msg"
Repo-per-project在组件化和使用Maven等工具简化构build方面具有优势。 通过限制开发人员正在改变的范围 – 在错误的垃圾提交方面增加了保护。
