是否有人在实际项目中使用新的git super/subproject功能？它的效果如何？例如,据我所知,如果我推送到子项目,我必须手动调用superprojects钩子(可能使用子项目钩子,但仍然)？
Von*_*onC 13
通过使用子模块,您在Git工作区(意味着您的"超级项目"Git存储库)中定义了一个配置.
"配置"是指"在工作区中工作所需的标签或SHA-1节点列表".
(通过工作,我的意思是你在工作区内做的"开发工作":经典编译,补丁,合并,部署,或......).
当您正在克隆超级项目和" git update"您的子模块时就是这种情况:您正在检查先前在超级项目中提交的确切存储库SHA1(在索引中记录为gitlink).
另一种模式是在处理超级项目和一个或多个子模块时.
这意味着,对于给定的子模块,您已检出特定分支(您不再使用分离的HEAD作为该子模块的内容,而是指向分支尖端的指针).
然后,"推送子模块"意味着更新包含该子模块(并且仅包含该子模块)的远程存储库.
在最后一个场景中的实际技巧(可能需要一个你想要的钩子)是你推动超级项目的时候:你需要确保首先推送所有的子模块.
从子模块教程:
始终在将更改发布到引用它的超级项目之前发布子模块更改.如果您忘记发布子模块更改,其他人将无法克隆存储库(超级项目)
不要忘记您可以配置子模块以跟随分支.
小智 12
FWIW,我们正在努力实现git的飞跃,而我们的项目(bitweaver,一个内容管理系统)是一个高度模块化的系统,拥有近160个存储库)."构建"通常包含二十二个或更多个子存储库.我们在CVS中使用了"虚拟模块",这对我们来说非常有用,但是CVS对于提交提交有自己的限制.
Git子模块有一些严重的局限性,你肯定应该评估mercurial的实现,因为它对外部/模块化项目来说肯定更友好和灵活(即它支持其他VCS系统,甚至是HgGit).
以下是最大的挑战:
当您在超级存储库中"git submodule add"时,每个子模块都与特定提交硬链接.这是设计,并由git维护者寻求好处,所以我不希望它很快改变.这在像我们这样的系统中是痛苦的,其中提交总是在子模块中发生.您必须更新超级项目才能跟上,或者在初始子模块更新后将子目录更新为主站.(有关我们的解决方案,请参阅下面的supergit).
您不能轻易地从根提交并推送到所有子仓库.这也很烦人,请参阅下面的supergit.
可能令人难以忍受的各种陷阱,特别是"无声地覆盖变化"的事情.
supergit
我们编写了一个shell脚本调用supergit来处理一些痛苦.它一举完成了克隆,子模块初始化,更新和结帐大师.它还将单独执行git命令到super-repo中的所有目录(批量git处理各种类型).
HTH,祝你好运.
| 归档时间： |
|
| 查看次数： |
13820 次 |
| 最近记录： |