Git cherry是否选择了正确的方法来备份和整合主题分支修复？

以下是我的设想：

假设我想修复github上的一个开源项目。在高层，我遵循以下工作流程：

• 在github上创建源项目
• 本地克隆fork
• 创建一个主题分支
• 做我的修正（在这里挥手示意不相关的细节…）
• 将主题分支推送到github
• 向原始源项目提交拉取请求

好的，现在让我们假设我已经做过几次了，所以我有主题分支称为issue#123和issue#456。除了主分支之外，原始源项目还有发布分支，例如1.0、1.1等

我有自己的独立项目，它使用这个开源项目的1.1版。我不想针对开源项目的“主”进行构建，因为它还不稳定。我需要的是开源项目1.1分支的本地版本，其中还包括我对issue#123和issue#456的修复

抱歉设置太长。。。无论如何，我目前正在做的是创建一个名为my-1.1（从1.1分支）的本地分支，cherry从我的主题分支中选择修复，然后构建它，并在我独立的依赖项目中使用结果

我不是100%确定樱桃采摘是正确的方式，但合并似乎并不正确，因为我不希望master（在我的主题分支中）的所有1.1后更改都流入“my-1.1”分支。这是最好的方法吗？有什么需要注意的地方吗

---

我唯一能想到的另一种方法是为每个补丁创建重复的主题分支，一个在branch off master中，一个在branch off 1.1中。然后我可以将基于1.1的主题分支合并到my-1.1中，而不是从基于主主题的分支中挑选提交。但这似乎是一个大麻烦。

您要做的是将您的主题分支从最旧的分支中分离出来，然后您可以将其合并到这两个分支中，而不会意外地包含较新的内容。换句话说，首先在1.1中进行修复，然后将其合并到master中，而不是反过来。

否。这是git rebase的完美用例。假设您的主题分支是

topic123

从

master

分支而来。相反，您希望将其分支为

1.1

。只需发出以下命令：

git rebase --onto 1.1 master topic123

假设

topic123

不依赖于

1.1

和

master

之间引入的代码，那么就可以了。如果它确实依赖于该代码，那么整个练习无论如何都会失败，因为您在1.1版本之后依赖于代码

git checkout 1.1 && git merge topic123

对所有主题分支重复此操作。您已经在远程分支上发出了pull请求，因此，假设您已经完成了对主题分支的编码，那么主题分支的本地副本具有较旧的合并基础这一事实并不是什么大问题。这样写的话，如果你想把它们放回

master

的顶部，只需反转参数：

git rebase --onto master 1.1 topic123

或者，如果您不想处理强制推送，请重置为远程设备的副本：

git reset --hard <repo>/topic123

git重置——硬/topic123

Hmm，但我想将我的主题分支推送到github上的分支，并从那里向原始源项目的主分支提交一个拉请求。如果我的主题分支是基于1.1的，那么它会起作用吗？（很抱歉这个可能很愚蠢的问题；仍在试图掌握git的窍门……）这取决于维护人员。他们可能会接受一个基于1.1的版本，或者您只需将其合并或重新设置到您的

主版本上

，然后将其提交给您的拉取请求。但1.1是否可能包含不应进入主版本的提交（我的修复除外）？如果我将基于1.1的主题分支合并到master中，master将得到的不仅仅是我的修复，对吗？也就是说，它将在脱离主控后获得1.1中的所有内容，以及我的修复。如果我误解了，很抱歉。通常，进入维护分支的所有内容也会合并到开发分支中，但如果没有，您可以使用

git merge base

找到它们的最后一个共同点，并从那里进行分支。好的，我必须彻底重新阅读rebase手册页，但现在我明白了（或者，不管怎样，我比以前得到的更多）。然而，我不想仍然需要一个单独的my-1.1分支来包含我的累积1.1修复，与1.1分支不同吗？似乎我想保持一个“干净”的1.1，它可以与上游/1.1保持同步……尽管我想如果它（上游/1.1）的话，这是不必要的已冻结。但如果它仍在发展（1.1 RC1，1.1 RC2），则继续重定基址以使我的修复保持在1.1提示可能会很痛苦。@AndyD Nah。一旦合并基数为1.1（比如今天的快照），您可以使用干净的

git merge topic123

将其合并到1.1中，无论它在何处发展。没有理由您不能将

git拉向上游。万一它发生冲突，您可能希望重新设置功能分支的基础或裁决冲突，因为您的修复可能不再适用。谢谢，Christopher，我感谢您提供的详细信息答复。