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

在以下方面,指导方针很简单: Git limits

• 主要项目 submodules .

一切 在一个巨大的git回购中,但构建一个小型回购作为主要项目,它将引用其他回购的正确承诺,每个回购代表一个项目或其自身的公共组件。

OP Paul Alexander comments :

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

• 直接从主项目中开发子项目(如中所述) True Nature of submodules
• 或者你在次级回购中引用 origin 对于其他地方正在开发的相同的次级回购:从那里你只需要从该次级回购中提取其他地方所做的更改。

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

老实说,这听起来像是一个真正的痛苦和任何需要开发人员做一些手动每次只是将是一个经常性的错误源维护。
我想我会考虑在超级项目中使用一些脚本来实现自动化。

老实说,你可能是对的。。。直到最近 Git release 1.7.1
git diff 和 git status

也就是说:

• Why are git submodules incompatible with svn externals? "
• 管理子模块可能很棘手:请参阅“ How exactly does git submodule work? ".

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

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

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