“分层”git存储库

Question

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

我有一个存储库，它包含整个网站结构，而web根位于存储库的根中。一切都很好，直到它变成了一个站点的存储库。然而，相同的回购现在被用于几个网站-基本上相同的网站，在不同的语言，小的模板调整，不同的图形等。这些东西是自然版本。

有一个主分支，它保存站点的原始源代码，我希望让主(或其他分支)保存在所有站点上都是通用的代码，因为最终会有太特定于站点的更改，而不会包含在回购的通用部分中。

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

嗯，这似乎是个好主意，直到我开始到处改变。

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

现在，对我来说真正的“问题”是当我改变了主人，然后我想复制所有这些变化到所有的分支。当然，考虑到所有分支都是主分支的后代，而且I do希望在所有站点*分支中进行这些更改，我切换到每个分支并合并主服务器。

这为所有的分支机构创造了一个相当难看的历史。每一轮合并都会使图表变得相当复杂，这使我得出两个结论：

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

为了说明我的“问题”，我将给出创建这些分支后得到的图形图像，添加几个特定于分支的提交，挑选其中的几个，添加并合并一个从主分支到所有分支的提交，提交到特定的分支，然后再进行一个主到全部的合并。

​

​

我不知道，我喜欢简单，也许我不习惯看到像这样的难以跟踪的图形(恐怕这只会随着每次合并而变得越来越复杂)。

我想我可以一路上做樱桃，有整洁的历史图表，但这听起来也不对，因为我可能会连续提交几次，然后忘了把其中一个提交到其他分支.

所以..。有什么你不介意分享的想法、经验和建议？

更新：--我选择了在我对已接受的答案的评论中描述的解决方案。感谢每一个做出贡献的人！

更新2: --尽管它与这个问题并不紧密相关，但似乎适合于任何有组织的开发周期，GIT作为DVCS的基础。这是一个很好的阅读。推荐。

Answer 1

备选答案：

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

原来的答案：

更改主分支后，可以将其他分支重新定位到更新的主分支上。让我们假设您拥有基于主服务器的某些提交的pl_site，并且主服务器已经更改：

 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现在包含在主服务器上所做的更改。

命令：

$ 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历史不会变得如此复杂以至于您无法再理解它。

新分支、新项目和将事物重构为库之间的权衡是一种微妙的权衡。维护大量的修补程序集要比维护大量使用公共库的项目集合要多得多，重构所需的(大量)工作量可能很快就会得到回报。也可能不会。