"分层"git存储库

mr.*_*r.b 6 git repository-design git-branch

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

我有一个存储库,它包含整个网站结构,而web根目录在存储库的根目录中.一切都很好,直到那是一个站点的存储库.但是,同一个repo现在用于几个站点 - 基本上是相同的站点,不同的语言,次要的模板调整,不同的图形等等.这些东西自然是版本化的.

有一个主分支,它拥有该站点的原始源代码,我希望拥有主(或其他一些分支)来保存所有站点中通用的代码,因为最终会有太多站点的更改 - 具体包括在回购的通用部分.

接下来,每个使用此源代码的站点都有一个分支.所有这些分支(例如,site1,site2site3)都是从master分支创建的,每个站点都克隆正确的分支.

好吧,这似乎是一个好主意,直​​到我开始到处改变.

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

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

这为所有分支创建了一个非常令人讨厌的历史.每轮合并都会使图形变得相当复杂,这使我得出两个结论:

  1. 这种分层分支的方式可以工作,只要我看着我的步骤而不做任何愚蠢的事情,而不是试图从全分支历史图中得到任何意义.要么..
  2. 必须有一些更好,更合适的方法来做到这一点.

为了说明我的"问题",我将在创建这些分支后添加一个图形图像,添加一些特定于分支的提交,挑选其中几个,添加并合并一个从master到所有分支的提交,提交或两个到特定的分支,然后再一个master-to-all merge.

一种不那么简单的历史图表

我不知道,我喜欢简单,也许我不习惯看到像这样的难以理解的图形(这种情况只会随着后续的每次合并而变得越来越复杂,我担心).

我想我可以一直采摘樱桃,并且有完整的历史图表,但这听起来也不正确,因为我可能会连续几次提交,然后忘记选择其中一个分支. ..

那么......你不介意分享任何想法,经验和建议吗?

更新:我选择了我对已接受答案的评论中描述的解决方案.感谢所有贡献的人!

更新2:尽管它与这个问题并没有紧密相关,但最近我偶然发现这种分支模型似乎适用于几乎任何有组织的开发周期,GIT作为底层DVCS.这是一个非常好的阅读.推荐的.

ral*_*nja 4

替代答案:

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


原答案:

当主分支更改后,您可以将其他分支重新建立到更新的主分支上。假设您有基于 master 上的某些提交的 pl_site 并且该 master 已更改:

 o---o---o---o---o  master
         \
          o---o---o---o---o  pl_site
Run Code Online (Sandbox Code Playgroud)

重新设置 pl_site 基础后,它将如下所示:

 o---o---o---o---o  master
                  \
                   o'---o'---o'---o'---o'  pl_site
Run Code Online (Sandbox Code Playgroud)

请注意,pl_site 的 rebased 版本上的提交是新的。pl_site 现在包含在 master 上所做的更改。

命令:

$ git checkout pl_site
$ git rebase master
Run Code Online (Sandbox Code Playgroud)

  • @mr.b:是的,它应该非常简单。只要尝试一下,直到找到您满意的解决方案。请记住,如果出现问题,您仍然拥有原始存储库:) (2认同)