这是我的场景：
假设我想修复 github 上的一个开源项目。在高层次上，我遵循以下工作流程：
- 在 github 上 fork 源项目
- 在本地克隆叉子
- 从 master 创建一个主题分支
- 进行修复（在这里挥手无关的细节......）
- 将主题分支推送到 github
- 向原始源项目提交拉取请求
好的，现在假设我已经这样做了几次，所以我有名为 issue#123 和 issue#456 的主题分支。原源项目，除了master分支，还有release分支，比如1.0、1.1等。
我有自己的独立项目，使用这个开源项目的 1.1 版。我不想针对开源项目的“大师”进行构建，因为它还不稳定。我需要的是开源项目 1.1 分支的本地构建，其中还包括我对问题#123 和问题#456 的修复。
很抱歉设置冗长......无论如何，我目前正在做的是创建一个名为 my-1.1 的本地分支（从 1.1 分支），从我的主题分支中挑选修复程序，然后构建它并使用结果我独立的、依赖的项目。
我不是 100% 肯定樱桃采摘是正确的方式，但合并似乎不正确，因为我不希望 master 的所有 1.1 后更改（它们存在于我的主题分支中）流入“my-1.1”分支。这是最好的方法吗？有什么需要注意的问题吗？
我能想到的唯一另一种方法是为每个修复创建重复的主题分支，一个在 master 的分支中，一个在 1.1 的分支中。然后我可以将基于 1.1 的主题分支合并到 my-1.1 中，而不是从基于主的主题分支中挑选提交。但这似乎是个大麻烦。