git-flow: 如何防止在发布分支上进行的某些更改合并回开发分支

Question

这个问题涉及到 git-flow方法论的一些边缘案例。

我的git-flow历史记录大致如下：

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

Git-flow 告诉我们将 release-3.5.0 分支合并到 development，然后发布就准备好了。因此，最终我们会将在发布分支上进行的所有更改合并到开发分支中。

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

现在想象一下，我们在发布分支上有一个提交“X”，但我们不希望在开发分支上出现，例如它是某种已经通过提交Y以更合理的方式在开发中修复的黑客/热修补程序或其他内容。

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

所以，主要问题是如何处理这种情况？如何防止此提交（或提交）重新进入开发流程？

- Olegas

---

可能是git-合并时跳过特定提交的重复问题。 - Ilya Serbis

Answer 1

虽然推荐使用rebase或合并/撤销/压缩的答案是可行的，但我个人认为更好的答案应该是：

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

- twalberg

---

--no-commit 不会生成“合并信息”。发布分支不会显示在历史记录中作为已合并，也不会被像 git branch --merged 这样的命令视为已合并。因此，一个人可能会因错误而再次意外地合并它。 - Olegas

@Olegas 尽管您的评论在技术上是正确的，但遵循上述完整的工作流程将创建“合并信息”（如果您指的是一些组合格式化的合并提交消息和/或创建历史DAG中合并的父指针），但最终的 git commit 才会创建它们。git merge --no-commit 只是设置了适当的元数据，以便可以创建。如果您在最终的 git commit 之前尝试 git branch --merged，它将正确地显示该分支尚未合并，因为合并尚未提交... - twalberg

是的，你说得对。提交后一切都正常了，包括合并信息，我错了。 - Olegas

Answer 2

在这种情况下，您总是希望完全合并发布（类似）分支。因此，请确保没有遗漏任何内容。

但是在合并过程中，您可以自由修改内容 - 包括删除或重新执行某些更改。对于您的示例情况，请合并分支，撤销您不喜欢的提交，并将该撤销压缩到合并提交中。显然，在合并提交消息中记下该操作。

如果修复程序已经在devel上，合并将直接跳过它，或者您可以通过选择devel版本来解决冲突。

关键是要使历史记录显示为第二张图，并以最合理的状态呈现。

- Balog Pal

Answer 3

您有几个选项：

1）使用git rebase -i 在此模式下，您可以将发行版分支重新定位到开发分支并排除第X个提交。 警告在这种情况下，您将会破坏现有的克隆存储库。

2）使用git cherry-pick 在此模式下，您将有可能逐个选择提交。

3）在单独的分支上使用git rebase -i，然后按照此答案中所指定的方式合并它：Is it possible to exclude specific commits when doing a git merge?

- StKiller

---

“rebase”不适合，因为你提到的警告，“cherry-pick”虽然可行，但因为我所拥有的发布分支有太多提交而过于复杂（但可以通过某种方式自动化）。 - Olegas

cherry-pick 实际上允许选择一系列提交记录（https://dev59.com/DHI-5IYBdhLWcg3wJE4K#1994491），但这也包括了一些问题（在相关回答中有说明）。 - StKiller

把答案更新了，加上了第三种方法。 - StKiller