我的团队正在使用git中的共享主题分支，我称之为“topic1”。我正在研究一个由topic1构成的分支上的一些代码的重构，我称之为“重构”。我一直在定期将topic1合并到重构中，因此我可以及时了解更改，但是还没有将重构合并到topic1中，因为重构仍在进行中。
还有另一个主题分支，我称之为“topic2”，最近是由master创建的。我想要做的是将仅仅我在“refactor”上所做的更改合并到一个由topic2构成的新分支，我将其称为“topic2_refactor”。 （I.E.提交中的更改只能由重构访问，但不能通过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等吗？
答案 0 :(得分：2)
您可以使用--onto选项尝试git rebase。这是什么允许是底垫操作抓住它需要从你的“重构”分支应用的diff，以关闭“TOPIC1”，但随后将其应用到“标题2”
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通常很不错。
因为它似乎重构是独立于这些话题的分支，我会考虑的重订重构分支关老爷的，所以当重构完成后，您可以合并这些变化到这两个主题。