Git分支策略问题

Question

目前，我们正在使用GitFlow方法来实现分支策略。但是我们遇到了以下情况。我们创建了一个发布分支。有一些错误需要修复发布分支。与此同时，自开发分支继续开发以来，还有其他的提交。在我们准备发布的那一点上，发布分支被合并为master。现在唯一要做的就是将发布分支合并回develop。当我尝试提升PR时，它显示没有区别，因为在（从时间轴的角度来看）修复在发布分支上完成之后，对相同文件有不同的更新。

我可以挑选某些变化或创建一个差异并在另一个分支中修补它并再次提出PR开发但是将来避免这种情况的通用解决方案是什么或者将这些修复带入的理想方法是什么？发展分支？

feature        x--x--x--x           x--x--x
              /          \         /       \
develop x----x------------x---x---x---------x-- ???
                               \               /
release                         x--x----------x
                                               \
master  x---------------------------------------x

Answer 1

我最初会问的主要问题是你在哪里创建你的标签。

1. 如果在master上创建，你应该将master合并回develop
2. 如果在release上创建，则master上的提交与标记不对齐

因此，使用git-flow，您似乎被迫在master上创建一个标记，然后将其合并到您的开发分支：

feature        x--x--x--x           x--x--x
              /          \         /       \
develop x----x------------x---x---x---------x-------x 
                               \                   /
release                         x--x----------x   /
                                               \ /
master  x---------------------------------------x 
     (1.0.0)                                 (2.0.0)

您主要担心的是能够从树上的任何位置执行git describe并查看正确的值。

为什么需要在develop上创建拉取请求？我会这样做：

git checkout develop
git merge master
git push

Answer 2

如果没有差异，拉请求应该只显示没有差异。因此，如果在发布分支上进行的更改也未在开发分支上进行，则PR绝对不应显示为空。除此之外，如果在开发的不同提交中做出相同的更改（例如通过从发布中挑选那些提交），git merge仍将创建合并提交，如果手动完成，即使您的托管解决方案中的PR不告诉你任何不同。

原则上你这样做的方式是绝对正确的...如果你使用的PR功能不允许你制作PR，手动进行合并或只是接受轻微的差异并继续前进。