git流：如何防止在发布分支所做的一些更改合并回开发中

问题是关于方法论的一些边缘案例

我有一些典型的git流历史，如下所示：

      o---o---o---o [release-3.5.0]
     /
----o---o---o---o---o [development]

Git flow告诉我们将发行版-3.5.0分支合并到开发中，然后发行版就准备好了。所以，最终我们将得到所有在发布分支到开发分支中所做的更改

      o---o---o---o 
     /             \
----o---o---o---o---o [development]

现在想象一下，我们在发布分支上有一个提交“X”，而我们在开发分支上不需要它，例如，它是某种黑客/热修复程序，或者在开发中已经以更合理的方式（即提交Y）修复了它

---

因此，主要问题是如何应对这种情况？如何防止此提交重新进入开发？

您有几种选择：

1） 使用

git-rebase-i

在这种模式下，您可以在开发分支上重新设置发布分支的基础，并排除Xth提交

警告在这种情况下，您将弄乱现有的克隆存储库

2） 使用git cherry pick

在此模式下，您可以逐个选择提交

3） 在一个单独的分支上使用
git-rebase-i
，然后将其合并，如以下回答中所述：
在这种情况下，您总是希望完全合并发行版（-like）分支。所以确保没有遗漏任何东西

但在合并过程中，您可以自由修改内容，包括删除或重做一些更改。对于您的示例，合并分支，恢复您不喜欢的提交，并将恢复的内容压缩为合并提交。显然，在该操作的合并提交消息中做一个注释

如果修复程序已经在devel上，merge将跳过它，或者通过选择devel版本来解决冲突

关键是你想让历史显示为你的第二个形象，以及最有意义的状态
 虽然建议重新设置基址和/或合并/还原/挤压的答案可行，但我个人认为更好的答案是：

git checkout development
git merge --no-commit release-3.5.0
# make whatever changes you need to fixup the "hack" and/or clean up any conflicts
git commit

rebase
不合适，因为“您注意到的警告，
cherry pick
是可以接受的，但太复杂的原因”发布分支我有太多的提交（但它可以自动完成）。cherry pick实际上允许选择一系列提交（），但这也包括一些问题（在链接的答案中指定）使用第三种方式更新了答案。
--no commit
不会生成“合并信息”。发布分支不会在历史记录中显示为已合并，也不会被类似于
git branch--merged
的命令视为已合并。因此，您可能会无意中再次错误地将其合并。@Olegas虽然您的注释在技术上是正确的，但按照上述完整的工作流将创建“合并信息”（假设您指的是合并格式的提交消息和/或在历史DAG中创建合并的父指针的某种组合），但是，最终的
git提交
创建了这些。git merge--no commit

只是设置了一些东西，以便创建适当的元数据。如果您在最后的

git提交之前尝试
git branch--merged
，它将正确地显示该分支尚未合并，因为合并尚未提交……是的，您是对的。提交后一切都很好，包括合并信息，我是错的。可能重复的
git checkout development
git merge --no-commit release-3.5.0
# make whatever changes you need to fixup the "hack" and/or clean up any conflicts
git commit