这是我的情景：
假设我想修复github上的一个开源项目。在高层次上，我遵循这个工作流程：
好的，现在让我说我做了几次，所以我有一个主题分支叫做问题＃123和问题＃456。除了主分支之外，原始源项目具有发布分支，例如， 1.0,1.1等
我有自己独立的项目，使用这个开源项目的1.1版本。我不想构建开源项目的“主人”，因为它还不稳定。我需要的是开源项目的1.1分支的本地构建，其中还包括我发布＃123和问题＃456的修复。
对于冗长的设置感到抱歉...无论如何，我目前正在做的是创建一个名为my-1.1的本地分支（分支1.1），从我的主题分支中挑选修复，然后构建并使用结果在我独立的依赖项目中。
我不是百分之百确定樱桃采摘是正确的方式，但合并似乎并不正确，因为我不希望所有的1.1后更改来自主人（存在于我的主题分支）流入“my-1.1”分支。这是最好的方法吗？任何需要注意的问题？
我能想到的唯一另一种方法是为每个修复创建重复的主题分支，一个分支关闭主分支，一个分支关闭1.1。然后我可以将基于1.1的主题分支合并到my-1.1中，而不是从基于主的主题分支中挑选提交。但这似乎是一个很大的麻烦。
答案 0 :(得分：1)
你想要做的是让你的主题从最旧的分支分支出来，然后你可以将它合并到两个分支中而不会意外地包含更新的东西。换句话说，首先在1.1中进行修复，然后将其合并到master中，而不是相反。
答案 1 :(得分：1)
没有。这是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