所以我们有template_site
这基本上是我们构建的任何网站的前端基础。
我们有cms
这是网站的后端并驻留在template_site/cms中，但它位于自己的存储库中，因为我们经常在没有template_site的情况下使用它
我们的模块中包含驻留在
中的文件 template_site/(all over the place)和cms/modules/(name of module)
基本上我们想要的是拥有
cms在它自己的回购中，
template_site中有cms_modules个自己的回购。
然后我们创建的每个模块都将其作为另一个存储库的分支。 template_site但我们只希望该存储库包含文件和对模块特定文件的更改，以便我们可以将模块拉入现有项目并使其仅影响这些文件。
问题在于，基本上所有部分都是关联的，但我们希望能够在处理模块时提取对cms的任何更改，并同时对template_site进行任何更改
此设置的原因是，对于我们创建的每个站点，我们希望将cms_modules克隆到其自己的存储库中，然后我们可以根据需要对其进行自定义。
我们怎么做？
或者这种设置有更好的工作流程吗？
我可以看到适当的设置是：
将cms回购列为“超级项目”
主分支机构中没有模块。
添加template_site作为子模块
添加cms_modules作为子模块
通过这种方式，我们可以将template_site repo克隆到它自己的存储库中并解决该问题，并且只在需要时才启动cms_modules子模块。
但我能在这里看到的唯一问题是我们希望template_site副本（对于新站点）或分支（对于新模块）来跟踪其根目录下的任何新文件，还要跟踪其中的任何更改或新文件。子模块，而不是让他们各自的存储库跟踪它们。
然后，如果对cms或cms_modules存储库进行更新，我们只需cd进入各自的目录并发布更新，但我们再次希望合并我们已更改的任何文件跟踪到{{1}}回购而不是相应的子模块。
如果我们想要添加另一个模块，我们可以在该模块的分支中合并。
我们怎么能设置它？
答案 0 :(得分：0)
回购结构： git submodules似乎是最适合您使用不受您控制的外部存储库的情况。您的想法是在当前存储库中移植不同的存储库，但部分技巧是外部存储库中的分支状态将包含“当前版本”的提交哈希子模块。换句话说，如果没有对外树的额外提交，外树将不会在内树中显示进度。这对外部案例很有意义 - 我不希望我的构建因我在我使用的库中的开发而被破坏 - 但在您的案例中似乎需要大量的簿记。
如果您要为每个站点创建一个全新的存储库，然后让cms成为其中的正确子模块，则更直观地使用子模块。这样，每个站点都可以与CMS文件夹的不同快照进行交互，并且只有在准备就绪时才会推出新版本。
存储库数量因为您的数据实际上在您的控制之下，所以拥有一个存储库对我来说是最有意义的。例如，如果其中一个目录足够大（以兆字节为单位）或者你的同事的一个子集只能访问其中一个，那么你可以为单独的存储库做一个好的参数，但除此之外，保持它们没什么好处存储库部分分开。
每个模块的分支：我倾向于同意堆叠溢出答案here，该答案建议反对在每个分支中放置完全不同的内容。在这种情况下，除非您自动或频繁地创建合并提交，否则将没有包含多个模块（或所有模块）的单个分支。 我首选的分支结构：创建一个包含所有模块和所有网站的 希望有所帮助！master分支。您仍然可以为每个模块或站点创建一个分支以简化开发，但是一旦代码看起来很好，就将分支合并到主服务器中。一段时间没碰过模块？删除分支 - 您可以随时重新创建它。