我喜欢Subversion设置的方式之一就是我可以拥有一个包含多个项目的主存储库.当我想在一个项目上工作时,我可以查看该项目.像这样
\main
\ProductA
\ProductB
\Shared
然后
svn checkout http://.../main/ProductA
作为git的新用户,我想在提交特定工作流程之前探索该领域的一些最佳实践.从我到目前为止所读到的,git将所有内容存储在项目树根目录下的单个.git文件夹中.所以我可以做两件事之一.
产品之间存在依赖关系,因此单个大型项目似乎是合适的.我们将使用一个服务器,所有开发人员都可以共享他们的代码.我已经通过SSH和HTTP工作了这部分我喜欢的部分.但是,SVN中的存储库已经有很多GB的大小,因此在每台机器上拖动整个存储库似乎是一个坏主意 - 特别是因为我们需要承担过多的网络带宽.
我想,Linux内核项目存储库同样大,所以必须有一个正确的方法来处理这个用Git,但我还没想到它.
是否有使用非常大的多项目存储库的指南或最佳实践？
Von*_*onC 65
关于Git限制,指南很简单:
这个想法不是将所有东西存储在一个巨大的git 仓库中,而是构建一个小型仓库作为主要项目,它将引用其他仓库的正确提交,每个仓库代表一个项目或它自己的共同组件.
这听起来类似于颠覆提供的"外部"支持.
我们尝试了这一点,并发现不断更新外部版本引用非常麻烦,因为项目是相互依赖开发的.还有其他选择吗？
@Paul:是的,不是从主项目更新版本,而是:
origin其他地方开发的同一个子仓库:从那里你只需要从那个子仓库中提取其他地方的变化.在这两种情况下,您都不要忘记提交主项目,以记录新配置.没有"外部"属性在这里更新.所有过程都更加自然.
老实说,这听起来像是一个真正的痛苦,任何需要开发人员每次手动做一些事情的事情只会成为维护错误的常规来源.
我想我会考虑使用超级项目中的一些脚本来自动执行此操作.
我回答:
老实说,你可能是对的......直到最新的Git版本1.7.1.
git diff并且git status都学会了考虑子模块状态,即使从主项目执行也是如此.
你根本不能错过子模块修改.
话虽如此:
| 归档时间： |
|
| 查看次数： |
60810 次 |
| 最近记录： |