我正在将基于SVN的版本控制的大型复杂多模块Maven项目移动到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大师都有一个聪明的想法，我可以用另一种方式做到这一点吗？
答案 0 :(得分：1)
这里的缺点是，可能需要使用补丁文件来完成项目之间的合并。
不。您已经拥有了正确的想法，在单独的存储库中管理单独的工作并根据需要合并它们。这正是＆＃34;遥控器＆＃34;是为了。
我们合并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
在主干分支上，你已经完成了。
如果你碰巧有工作，你不想打扰你当前的工作树，克隆一个轻量级的临时仓库，在那里进行合并并推回。您将发现存储库之间所有其他所需的通信同样是直接的。