将来会有一些子项目：“项目1”，“项目2”等。
此外，还有一个名为“基础项目”的项目，它是其他项目的基础。 “基础项目”是一个内容管理系统（CMS）。
所有项目都有自己的git存储库。
“项目1”，“项目2”和其他人使用“基础项目”来发展和成长。
git中有一些方法，比如submodule或subreemerge。但似乎不适合这里。 “基础项目”不应该克隆到子目录中。它在根目录中。它在“项目1”或“项目2”中不断增长......
当我在子项目中工作时，我必须能够将“基础项目”更改分别推送到它自己的存储库以获取其他子项。
我该怎么办？
答案 0 :(得分：3)
子树合并或子模块适用于 component-based development ：两个不同但连贯的文件组合在一起。
每组文件都在自己的目录中，因为它们可以独立分支或标记（子模块），或者一起（子树合并，同时保留恢复自己历史记录的能力）。
两者都需要一个单独的目录。
但是您所描述的内容（“Base Project”位于根目录中，增长为“project 1”或“project 2”）是关于 system-based approach ：所有组件合并为一个大型组件：一组大型文件将始终一起演变为一个单元。
因此，每个项目可以有一个分支：branch1为CMS-projet1，branch2为CMS-project2，依此类推。
但是，如果您需要将projectx - 特定修改或CMS特定修改报告回其原始（和单独）回购，则在专用分支中进行所述特定更改，然后将这些更改结合起来< /强>：
branchp1将用于影响project1 branchc1将用于影响CMS branch1将是branchp1和branchc1 （branch2同样的事情）
然后，您可以将这些更改导出为修补程序：
branchp1到project1 repo branchc1到CMS repo 不方便的是，Git不会记住已经合并回原始回购的内容，但这样您就可以将CMS-projectx个文件集中开发的常用历史记录报告回原始版本{{ 1}}和CMS回购。
注意：如果您不想管理2个额外分支，则另一个解决方案是：
projectx”或“[CMS] my CMS modification comment...”git-extract-patches导出仅作为补丁的正确提交。