我的团队正在git中创建一个共享主题分支，我将其命名为"topic1 "。我当时正在对一个由topic1组成的分支上的一些代码进行重构，我将其称为"重构"。我一直在定期地将topic1合并到refactor中，这样我就可以及时了解变化，但还没有将refactor合并回topic1，因为重构仍在进行中。
还有另一个主题分支，我将其命名为"topic2"，它是最近在master上创建的。我想做的是只将我在"refactor"上所做的更改合并到topic2的新分支中，我将其称为"topic2_refactor"。(即提交中的更改只能通过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等，这可能吗?
您可以尝试使用——onto选项git rebase。这允许rebase操作从'refactor'分支获取它需要应用的差异，基于'topic1'，然后将它们应用到'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通常在这方面做得很好。
既然看起来重构是独立于这些主题分支的，我将考虑将重构分支从主分支中分离出来，这样当重构完成时，您就可以将这些更改合并到两个主题中。