时间戳

首页 > 解决方案 > 将事物合并到生产/发布分支​​的正确方法是什么？

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

问题描述

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

为了正确地做事，我们正在尝试遵循类似于https://nvie.com/posts/a-successful-git-branching-model/中描述的 git 分支模型：

git分支模型

但是，与图片上显示的一个关键区别在于hotfixes分支：

这似乎是一个很小的差异，但它改变了事情：

让我们进入正题：

我刚才所描述的事情有些不对劲。完成后，我们所拥有master的不仅仅是发布候选。它是候选版本加上之前的修补程序提交。由于该提交中的更改不得保留在生产中，因此这是一个问题。

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

我的意思是，即使我们不需要提交，我也可以合并hotfixes到，用来忽略其中的内容，但这并不是解决这个问题的正确方法developgit checkout develop; git merge -s ours hotfixes

标签： git

解决方案

从大局来看，您的工作流程听起来很合理。

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

有两种情况：

简单的案例

分支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”和“x被添加到master”，因此，两者的添加是合并的结果。]

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

推荐阅读