在 tfs 迁移（完全不同的分支概念）之后，我必须将修复合并到多个发布分支，但分支并不相同，它们大多相似，但产品不同（例如不同的品牌、conn 字符串等），所以我可以不要在这里使用 nvie gitflow 一种产品分支策略。
https://github.com/MrKekson/stackoverflow_question/network
在这里你可以找到一个大大简化的分支结构，基本上我想将 hotfix1 分支从 b1 合并到 tesztb3，但没有之前在 b1 上的提交（c3，c4）。
Cherrypicking 或 rebase 可能会有所帮助，但我没有设法完成它，而且我在高级 git 使用方面还没有很多经验。所以请告诉我如何去做，或者我应该改变什么来完成它。
好的，我解决了。至少有几种方法可以做到：
所以基本上，可以在 hotfix1 到 teszt3 上分别挑选每个提交，但这很笨拙。
所以我们可以从 b1 创建一个合并分支，将 hotfix1 合并到其中，然后将合并创建的提交挑选到 tesztb3 中，这将在 testb3 上产生一个新提交。甚至可以将 -x 添加到 cherry-pick 中，因此它将使用其父 guid 在新提交上创建一个注释，或者我们可以将 hotfix1 分支压缩为 1 个提交，然后对其进行挑选。
或者我们可以根据最后一次提交（hf2）创建一个变基分支，然后
git rebase --onto <new-parent> <old-parent> <lastcommit>
--onto 在这里解释，但<new-parent>我们的目标分支是 teszt3，我更喜欢在目标分支上为此创建一个合并分支，旧父级是 hotfix1 的开始，在这种情况下 lastcommit 是 hotfix1 上的 hf2。然后将 teszt3 合并到我们的新合并分支，并创建一个拉回 teszt3 的请求。
所以我认为这两条路径乍一看都不容易，但有一点经验是可行的，而且这是一种更流畅的体验，然后在 tfsvc 中重命名目录。