3

我是一个相对的 git 新手。我有一个对我来说有点复杂的回购，我现在掉进了兔子洞。

我从一个拥有自己的 repo 的 Joomla 网站开始（我们称之为 Repo A）。该网站启动后，我们的客户希望我们开发 3 个类似的网站。在大多数情况下，这些站点是相同的，只是顶部有一些不同的样式。所以，我拿了回购 A 并将其分成 3 个新的回购（称它们为 B、C 和 D）。

随着时间的推移，我在 Repo A 中发现了需要发送给它的子代的 bug。为此，我在 Repo A 上创建了一个名为 shared 的分支。然后我会从“master”中挑选我需要分享的提交，并将它们带到“shared”。然后在子存储库中，我会从上游（存储库 A）拉入“共享”分支，以便获得最新的修复。正如您所想象的那样，这是一个非常笨拙的解决方案（所有“共享”分支提交也在“主”中结束，但具有不同的提交 ID）——但它有点工作。

现在这些网站已经成熟，我发现它们之间的共享越来越少。几乎所有提交都需要与另一个 repo 共享，但是所有 4 个 repo 都需要的提交并不多。我在想我应该组织更多的组件而不是站点。例如，组件 1 在回购 A 和回购 B - 组件 2 在回购 A 和 C - 组件 3 - 在回购 A、B 和 D 中 - 等等。

所以，对于我的问题：

  1. 假设我没有搞砸一切，处理这些共享组件的最佳方法是什么？这些应该是分支还是制作那些独特的回购更好？

  2. 有什么办法可以让自己脱离这个老鼠窝吗？我无法真正回顾我的历史并逐个提交移动，因为它们有数百个。我试图弄清楚是否有办法让它继续前进。我曾考虑将我的“组件”分支从 Repo A 的“共享”分支中分支出来，但我无法将该分支合并到 Repo A“master”中，因为我担心“ shared” 可能会撤消/覆盖自“master”上的cherry-pick以来发生的提交更改。我读过关于孤立分支的信息，但这似乎也不起作用，因为要求父母不要与现有分支发生冲突。

任何 git 大师都对如何让这个设置更有用有任何想法？非常感谢帮忙。

4

1 回答 1

0

The simplest way would be to keep your current history untouched, but:

  • remove the common files, and add them in a new Component repo
    (repeat that for every common Component you have identified)
  • declare the relevant ComponentX repos as submodules of your current existing repos.

It is easier than trying some git filter-branch to split your existing repos.

于 2014-03-17T08:19:02.527 回答