将奇异的 repo 结构从 SVN 移植到 Git

Question

我正在将大型复杂的多模块 Maven 项目从基于 SVN 的版本控制转移到 Git。

作为背景，整个项目曾经存在于一个 SVN 存储库中。该项目由许多后端/守护程序模块组成。一个核心前端模块，然后是一些特定于客户端的前端实现。

我们最终得到的是一个非常奇怪的结构（大约 5 年，因为这些事情往往会发生）。一切都在一个 SVN 存储库中，但每个模块都有自己的 trunk、tags 和 branches 文件夹和独立的发布周期。

在移植到 Git 时，我们决定将模块移动到它们自己的、独立的 Git 存储库中。我们使用了git svn，因此将每个模块及其trunk、tags 和branches 文件夹导出到Git 存储库中——保留标签和分支。

到目前为止一切顺利。

现在我遇到了一个我不知道最佳解决方法的问题。

我拥有的是一些特定于客户端的前端模块。这些主要包含模板和本地化文件 - 用于品牌推广等。

我们如何在 SVN 上做到这一点是我们有一个 Trunk 模块，它有 trunk、tags 和 branches。当我们需要为客户打造我们的产品品牌时，我们会将svn cp 两个全部 放入另一个文件夹，例如ClientA。

所以现在我们有

Trunk
    /trunk
    /tags
    /branches
ClientA
    /trunk
    /tags
    /branches

因此，这两个项目的工作继续独立进行。事物被独立标记、分支和合并。

但是如果在前端代码中发现错误，或者添加了有用的功能，我们合并Trunk/trunk <-> ClientA/trunk。因为整个项目是一个svn cp SVN 可以（几乎）优雅地处理这个合并。

那么我该如何在 Git 中做类似的事情呢？

我可以看到两种广泛的方法：

1) 将整个前端代码保存在一个 Git 存储库中，并为客户特定的项目命名分支。对分支和标签使用一些命名约定。这将允许我们跨分支合并。

这样做的缺点是它看起来真的 hacky。维护的噩梦（哎呀，我将功能分支合并到错误的客户端分支中）。而且还很丑。

2) 将项目分离到它们自己的 Git 存储库中。这具有清洁的主要优点。这些项目具有不同的生命周期，因此它们应该位于不同的存储库中。

这里的缺点是跨项目合并可能需要使用补丁文件来完成。

那么，有没有人有移植类似 Git 的经验。你做了什么？你如何维护它？你遇到过什么问题？吸取的教训？

是否有任何 Git 大师对我如何以另一种方式做到这一点有一个聪明的想法？

Answer 1

这里的缺点是跨项目合并可能需要使用补丁文件来完成。

不。您的想法完全正确，在单独的存储库中管理单独的工作并根据需要合并它们。这正是“遥控器”的用途。

我们合并 Trunk/trunk ↔ ClientA/trunk

开始条件：所有工作都在主Trunk存储库中，是时候在ClientA上工作了。做客户工作，

git clone u://r/l/Trunk -b trunk  ClientA # or /path/to/Trunk if your fs is shared

当需要将 Trunk 的主干分支上的工作合并到 ClientA 的主干分支中时，您可以在 ClientA 的存储库中执行以下操作：

git pull

在主干分支上，你就完成了。

如果您碰巧在当前工作树中有不想打扰的工作，请克隆一个轻量级临时存储库，在那里进行合并并将其推回。您会发现存储库之间所有其他所需的通信都是类似直接的。