“分层” git 存储库

Question

我每天都使用 git 一段时间了，这次我遇到了一个问题，我可以这样描述。

我有一个存储库，其中包含整个网站结构，并且网络根位于存储库的根目录中。一切都很好，直到它成为单个站点的存储库。然而，同一个存储库现在用于多个站点 - 基本上是相同的站点，使用不同的语言，小的模板调整，不同的图形等。这些东西自然是版本化的。

有一个主分支，它保存站点的原始源代码，我希望主分支（或其他一些分支）保存在所有站点上通用的代码，因为最终会出现过于站点的更改 -具体包含在回购协议的通用部分中。

接下来，每个使用此源代码的站点都有一个分支。所有这些分支（例如，site1、site2 和 site3）都是从 master 分支创建的，每个站点都会克隆正确的分支。

嗯，这似乎是个好主意，直​​到我开始在各处进行更改。

如果我在 site1 分支上进行了更改，并且需要将该更改复制到 site2 分支，我会选择从一个分支到另一个分支的提交。合并是不可能的，因为 site1 分支上还有其他不属于 site2 分支的更改。针对这种情况是否有其他更优雅的解决方案，或者挑选樱桃正是为了这个目的？

现在，对我来说真正的“问题”是当我更改主控时，然后我想将所有这些更改复制到所有分支。当然，考虑到所有分支都是 master 的后代，并且我确实希望在所有 site* 分支中进行这些更改，我切换到每个分支并合并 master。

这为所有分支创建了一个看起来相当令人讨厌的历史。每轮合并都会使图表变得相当复杂，这让我得出两个结论：

1. 只要我注意自己的步骤，不做任何愚蠢的事情，并且不试图弄清楚任何意义，这种分层分支的方式就可以工作所有分支的历史图。或者..
2. 必须有一些更好、更合适的方法来做到这一点。

为了说明我的“问题”，我将给出一张图表，该图像是在创建这些分支、添加一些特定于分支的提交、挑选其中一些、添加并合并从 master 到所有分支的一个提交、提交或两个到特定分支，然后再进行一个从主到所有的合并。

我不知道，我喜欢简单，也许我不习惯看到像这样的难以理解的图表（恐怕它只会随着每次合并而变得复杂）。

我想我可以一直进行挑选，并拥有整洁的历史图表，但这听起来也不正确，因为我可能会连续进行多次提交，然后忘记将其中一个提交到所有其他分支。 ..

那么...您有什么想法、经验、建议不介意分享吗？

更新：我选择了对已接受答案的评论中描述的解决方案。感谢所有贡献者！

更新2：尽管它与这个问题没有紧密相关，最近我偶然发现了这种分支模型，它似乎适用于几乎任何有组织的开发周期，以 GIT 作为底层 DVCS。这真是一本好书。受到推崇的。

Answer 1

替代答案：

您可以将抽象从分支级别移动到存储库级别。使用主分支创建一个主存储库。为每个站点克隆此存储库。当对主分支进行更改时，将这些更改拉入每个站点存储库。这样，每个存储库只需要一个主分支。

---

原始答案：

当主分支更改后，您可以将其他分支重新设置到更新的主分支上。让我们假设您有基于 master 上的某些提交的 pl_site，并且该 master 已更改：

 o---o---o---o---o  master
         \
          o---o---o---o---o  pl_site

在重新基化 pl_site 后，它将如下所示：

 o---o---o---o---o  master
                  \
                   o'---o'---o'---o'---o'  pl_site

请注意，重新基化版本的 pl_site 上的提交是新的。 pl_site 现在包含在 master 上所做的更改。

命令：

$ git checkout pl_site
$ git rebase master

Answer 2

我没有一个好的答案给你，因为你的问题很复杂，解决方案也很复杂。

选项 1：重构

您说过不同的站点“基本上是相同的站点”。因此，将它们移动到不同的项目，并将 main_site 单独保留在一个项目中。然后，其他站点将包含 main_site 作为子项目。

因此，对于横幅...

en_site/
en_site/images/banner.jpg
en_site/master/
en_site/master/images/banner.jpg

您的网站代码、配置脚本、部署脚本或其他任何内容将确保选择 images/banner.jpg 而不是 master/images/banner.jpg。也许当您部署站点时，首先复制 master/images，然后复制 images，也许您会做一些更复杂的事情。

这可能需要大量工作。但是，当您查看历史记录时，您会得到如下信息：

en_site: A -> B -> C -> D
de_site: E -> F -> G -> H -> I
main_site: J -> K -> L -> M -> N -> O

选项 2：使用 Darcs

在 Darcs 中，您可以将补丁从一个分支移动到另一个分支。一些商业 VCS 或许也可以做到这一点。因此，您的分支将如下所示：

master: patch1 patch2 patch3 patch4
en_site: patch1 patch2 patch3 patch4 en1 en2 en3
de_site: patch1 patch2 patch3 patch4 de1 de2 de3

假设您要将补丁 en2 移植到德语站点。

de_site: patch1 patch2 patch3 patch4 de1 de2 de3 en2

瞧。然而，这并不像看起来那么干净。 Darcs 爱好者会指出，这个补丁模型与我们的“将补丁移动到另一个分支”的概念模型相匹配，但是，这掩盖了这样一个事实：您仍然需要进行测试以确保 en2 当您将补丁放在 de_site 上时，它不会破坏所有内容。

例如，如果 en2 对代码中与 de1 相同的部分进行了更改，会怎样？然后呢？无论您使用什么 VCS，都必须手动合并。对于像这样的每个明显情况，还有一种 VCS 无法检测到的情况，您必须自己检查。

我的经验

当我第一次开始使用 git 时，git merge 似乎很神奇。然而，再多的 VCS 欺骗也无法掩盖这样一个事实：您的站点具有一些非常复杂的相互依赖关系。您可以重构您的站点以消除相互依赖性，或者希望您的 VCS 历史记录不会变得如此复杂以至于您无法再理解它。

新分支、新项目和将内容重构到库中之间的权衡是一个微妙的权衡。维护大量补丁集比维护大量都使用公共库的项目要多得多，重构所需的（大量）工作可能很快就会得到回报。或者也可能不会。