我有 3 个具有类似组织的 git 存储库和它们之间的一些重复目录。它们是一个大项目的子项目。
Proj1/
.git/
feature1_lib/
feature1_app/
feature1/ <- specific to Proj1
feature2_lib/
...
Proj2/
.git/
feature1_lib/
feature1_app/
feature1/ <- specific to Proj2
feature2_lib/
...
Proj3/
.git/
feature1_lib/
feature1_app/
feature1/ <- specific to Proj3
feature3_lib/ <- specific to Proj3
feature3_app/ <- specific to Proj3
feature3/ <- specific to Proj3
...
它们是同时开发的,但历史略有不同。
Proj1/
...
commit4 "Commit specific to Proj1."
commit5 "Add code to feature1_lib."
commit6 "Fix bugs in feature1_lib."
commit7 "Refactoring in feature1_lib."
...
Proj2/
...
commit6 "Import changes from Proj1." <- after commit7 in Proj1
commit7 "Commit specific to Proj2."
commit8 "Fix bugs in feature2_lib."
commit9 "Add code to feature2_lib."
...
等等。
现在我正在寻找切割和粘合重复零件的选项。我认为它应该看起来像这样
Proj1_2_common/
.git/
...
Proj1_2_3_common/
.git/
...
Proj1/
.git/
...
Proj2/
.git/
...
Proj3/
.git/
...
我阅读了有关子树和子模块的信息,但并不完全理解。如果我可以将我的项目指向某个目录,为什么我必须制作子树?也就是说,"feature1_lib/"
我可以简单地重新配置我的项目以查看"Proj1_2_3_common/feature1_lib/"
.
那么从您的角度来看,这里有什么更好的选择?什么是最简单的?如何处理如此凌乱的历史,以便在运动后有一些参考?