将修补程序应用于主程序的中间提交

Question

下面是遵循的Gitflow工作流，其中master分支具有不同版本的提交历史(git tag)。

从发行版mgmt方面来说，我们在与master和develop分支合并后删除D3分支。

​

要应用热修复，我们首先从git checkout分支创建特定的发行版提交，然后根据该特定提交创建一个热修复分支(如下面橙色显示)并进行更改。

​

问题：

1) git merge是否允许热修复分支合并到master分支上的中间提交节点(如下面所示)？而不是合并到master的提示，因为修补程序是用于0.1发行版的

2)如果不是，如何通过master分支应用(特定版本的)修补程序？因为release分支被删除了

Answer 1

您实际上是在问如何管理多个生产版本。Gitflow没有涉及到这一点，这是一个复杂的话题。

您可以在每个支持的版本中都有一个分支，例如version/1.9.0，并执行“嵌套gitflow”，将该版本分支处理得与主版本一样。在您想要备份/转发端口修复之前，这应该足够好。

不幸的是，我没有任何经验，所以没有比这更多的帮助。

要回答字面上的问题：

这是不可能的一个人可以重新建立以下所有的历史，但这会造成如此多的不便和麻烦，这不是一个选择。

Answer 2

正如marstato所说，您需要多个版本分支才能支持多个次要(或主要)版本。在这些版本分支的旁边，您将拥有修复分支。你没有真正的支部了。

因此，在您的情况下，您有一个version/0.1、version/0.2和version/0.3分支。以及fix/0.1、fix/0.2和fix/0.3分支。当在您应用于fix/0.1分支的0.1版本中发现错误时，将该修复分支合并到version/0.1和fix/0.2中。然后将fix/0.2和fix/0.3合并(以此类推)。最后，您将最后一个修复分支合并到相应的版本和分支中，并合并到您的开发分支中。

当您不再需要支持某个版本时，您可以删除该版本并修复该版本的分支，并在合并时跳过它们。

请注意，这会带来大量开销，当然，在支持许多版本时也是如此。您可以通过定期合并修复分支来减少开销，但这会引入一个问题，即让您的测试团队知道哪个修补程序已经在哪个版本中合并了。

下面是一个带有0.1和0.2版本的简短示例。

Answer 3

您的基本问题是将提交注入提交历史，这与重写Git历史非常相似。您可以使用rebase interactive来完成这个任务。请注意，您可能需要处理合并冲突。见这里：

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

请参阅关于Reordering提交的部分。如果不知道确切的提交历史记录，就不可能提供所需的命令。因此，我将简单引用上面的网页链接：

Reordering提交您还可以使用交互式重基来重新排序或完全删除提交。如果要删除“Add file”提交并更改引入其他两次提交的顺序，则可以从以下内容更改重基脚本：

pick f7f3f6d Change my name a bit
pick 310154e Update README formatting and add blame
pick a5f4a0d Add cat-file

对此：

pick 310154e Update README formatting and add blame
pick f7f3f6d Change my name a bit

当您保存并退出编辑器时，Git会将您的分支重卷到这些提交的父节点，然后应用310154e，然后应用f7f3f6d，然后停止。您可以有效地更改这些提交的顺序，并完全删除“Add file”提交。