我有一个CMS框架，我用于多个项目，由我编码。当我做我的项目时，CMS得到了改进，我经常想在后续项目中使用这些更改。 通常，我一次有多个项目。
在阅读git之后，我知道我可以分支每个项目并将CMS改进提交回master，然后重新分配给其他分支，但这似乎是错误的。特别是在一些项目完成后的几年中，但核心CMS看起来与使用它时的情况大不相同。它还意味着在项目之间切换时在分支之间切换。当我在那台机器上创建回购时，我用它的每台机器也会获得每个分支的副本吗？
另一种选择似乎是克隆。我有一个包含“核心”CMS的主要仓库，每个项目都成为这个项目的克隆，并且单独处理。这似乎更直观，但是我可以将克隆中的一些更改合并回核心，并且可以将核心更改分发给其他克隆吗？
编辑： 更多地考虑一下，克隆是我认为将一个回购复制到一台机器上的术语（我使用了几个，我希望与一些项目的最新版本保持同步）。那么也许我应该''求'？这只是一个github的事情吗？
两种选项都是正确的方法吗？所有建议表示赞赏
答案 0 :(得分：0)
我实际上遇到了类似的问题。所以我做的是创建2个存储库。一个具有应用程序的核心，每个实例必须具有才能工作。
在每个实例的特定文件和配置的存储库之上。
core-repo标有版本号，其中核心主机上的每个标签都是工作版本。
这允许签出特定标签并将单个数据保存在实例回购中。你不能用这个设置做的是在实例repos中使用keepong特定代码并将其合并到其他实例中。你可以做到这一点，如果你只需要一个实例仓库并在那里分支每个实例，或者你可以使用lile composer（www.getcomposer.org）来保持你的依赖关系。
答案 1 :(得分：0)
另一种选择似乎是克隆。我有一个主要的回购包含 “核心”CMS，每个项目都成为了这个项目的克隆，并且正在进行中 分别。这似乎更直观，但我可以合并一些 将克隆更改为核心，我可以将核心更改分发到 其他克隆？
对于遇到这种情况的任何其他人来说 - 克隆是走到这里的方式。
它允许您将所有站点作为计算机上的单独文件夹，因此您可以轻松切换而无需检查分支机构等。
然后，它允许您将每个克隆的更改推送到生产服务器和/或返回到核心存储库（源）。然后，从原点开始，您可以将更改推送到您喜欢的任何其他实例。
巧妙地使用.gitignore，--assume-unchanged并调整每个项目以获得“主题”文件夹意味着您可以推动所有更改，而不必担心一个网站个性覆盖另一个网站。