2

我的团队正在 git 中开发一个共享主题分支，我将其称为“topic1”。我正在对由 topic1 构成的分支上的一些代码进行重构，我将其称为“重构”。我一直在定期将 topic1 合并到重构中，以便我可以及时了解更改，但没有将重构合并回 topic1，因为重构仍在进行中。

还有另一个主题分支，我称之为“topic2”，它是最近从 master 创建的。我想做的只是将我对“重构”所做的更改合并到一个由 topic2 构成的新分支，我将其称为“topic2_refactor”。（即提交中的更改只能通过重构访问，但不能通过 topic1 访问。）

我知道如何看到这些变化：

git log origin/refactor --not origin/topic1

所以我想做的是这样的——但这种语法不正确：

git checkout topic2
git checkout -b topic2_refactor

然后这个：

git merge origin/refactor --not origin/topic1

或这个：

 git cherry-pick origin/refactor --not origin/topic1

（以上似乎导致了不必要的合并冲突，因为 master 上发生了一些更改，后来又合并回了重构分支。）

我希望有一种干净的方法来做到这一点，并避免不必要的合并冲突，这些冲突后来在“重构”分支的历史中得到解决。这可能使用 git rebase、git filter-branch 等吗？

4

1 回答 1

2

您可以尝试git rebase使用--onto选项。这允许 rebase 操作根据“topic1”从“refactor”分支中获取它需要应用的差异，然后将它们应用到“topic2”

git co refactor
git co -b topic2_refactor
git rebase --onto topic2 topic1 # bases the diffs off of topic1, but applies them to topic2

您的成功可能会有所不同。仍然可能发生有问题的冲突。这样做的缺点是您现在将拥有两个具有相同更改的独立重构分支，但是由于这是一个变基，因此它们具有不同的历史记录，如果您不小心，很容易出现分歧（您必须不断地从中挑选一个分支到另一个或类似的东西）。

然后，当 topic1 和 topic2（重构后）都需要再次合并到 master 时，您可能会遇到麻烦，因为它们将拥有所有相同的重构提交。尽管 git 通常对此非常好。

由于重构似乎独立于这些主题分支，因此我会考虑将重构分支从 master 中重新定位，因此您可以在重构完成后将这些更改合并到两个主题中。

于 2011-04-21T19:55:16.603 回答