将事物合并到生产/发布分支​​的正确方法是什么？

Question

我和我的团队目前正在做一个小项目。

为了正确执行操作，我们尝试遵循类似于https://nvie.com/posts/a-successful-git-branching-model/中所述的git分支模型：

与图片显示的一个主要区别在于hotfixes分支：

• 当生产中出现错误时，我们必须尽快修复该行为，并且我们通常必须通过临时解决方案（不应该进行硬编码的硬编码内容等）来做到这一点。此解决方案在hotfixes上开发，然后合并到master（这是生产分支）
• 一旦事情在生产中趋于平静，我们会更深入地研究问题，并在develop上正确解决此问题。在某些情况下，该问题还可能会由于其他更改（例如，通过合并一个功能部件分支，该功能部件可以完全删除错误代码。无论哪种方式，问题的关键在于部署在生产环境中的临时hack永远不会进入develop

这看起来似乎是一个很小的差异，但是它改变了一切：

• 有时，develop上的内容放在发布分支上（我们称之为develop）
• 在进行了一些测试和修复之后，候选发布版本已准备就绪，可以进入生产分支，因此我们需要将pre-release合并到pre-release中。我们叫master，我们完成了……除了我们没有

让我们重点讲一下：

我刚才描述的东西有很多错误。完成之后，在git checkout master; git merge --no-ff pre-release上拥有的不仅仅是候选版本。这是以前发布的修补程序提交的候选版本 plus 。由于该提交中的更改一定不能保留在生产中，所以这是一个问题。

所以这是一个问题：如果master在这里是错误的，将git checkout master; git merge --no-ff pre-release合并到pre-release的正确方法是什么？

我的意思是，即使我们不需要提交，我也可以将master合并到hotfixes中，使用develop忽略其中的内容，但是感觉不太像解决此问题的正确方法

Answer 1

您的工作流程听起来很不错。

关于修补程序，您必须更改的一件事是，您必须引入可逆转不需要的修补程序解决方案的提交。

有两种情况：

简单的情况

分支develop不会使此修补程序不必要。充其量，您只需从该修补程序中分支出来，然后在其上提交git revert HEAD^，然后将此提交合并到develop中。现在，您可以像往常一样继续在develop或还原的修补程序之上彻底解决问题。

复杂的情况

分支develop使此修补程序过时。要覆盖此修补程序的更改，请先将修补程序的父级合并到develop，然后使用git merge -S ours忽略此修补程序的更改。

请考虑以下分支历史。将每个节点名称ABC视为文件的内容。

       ABC
      /   \
     |  / ABCx    <- hotfix (on master)
   ABDC | /|      <- change on develop makes hotfix obsolete
     | / / |
     v  /  |      <- git merge hotfix^ into develop
    ABDC   |      <- git merge -S ours hotfix into develop
      \   /
      ABDC        <- git merge develop into master

[编辑：这是错误的：如您所见，最后一个git merge看到“ D被添加到develop”和“ {{1 }}被添加到x“上，因此，两者的添加是合并的结果。]

以常规方式在修补程序之前合并提交非常重要，否则master也会忽略修补程序之前的所有未合并更改。