Git分支策略问题

目前，我们正在使用GitFlow方法来实现分支策略。然而，我们遇到了以下情况。 我们创建了一个发布分支。发布分支上有几个bug需要修复。同时，由于开发分支机构的开发工作仍在继续，因此有额外的承诺。在我们准备发布时，发布分支被合并到master。现在唯一要做的就是将发布分支合并回develope。当我尝试提交PR时，它没有显示任何差异，因为在发布分支上完成修复之后（从时间轴的角度来看），相同的文件有不同的更新

我可以选择某些更改，或者创建一个diff并在不同的分支中进行修补，然后再开发一个PR。但是，将来避免这种情况的通用解决方案是什么，或者将这些修复程序转移到开发分支中的理想方法是什么

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

---

我最初要问的主要问题是，在哪里创建标记

如果在

master

上创建，则应将

master

合并回

developer

如果在

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 description，并查看正确的值

为什么需要在

develope

上创建拉取请求？我只想这样做：

git checkout develop
git merge master
git push

---

只有在没有差异的情况下，拉取请求才会显示没有差异。因此，如果在发布分支上所做的更改不是在开发分支上所做的，那么PR绝对不应该显示为空。除此之外，如果在开发时在不同的提交中进行了相同的更改（例如，通过cherry从发行版中选择这些提交），则如果手动执行，

git merge

仍将创建合并提交，即使宿主解决方案中的PRs没有显示任何差异

---

原则上你这样做是绝对正确的。。。如果您使用的PR功能不允许您进行PR，请手动进行合并，或者接受细微的差异，然后继续。

因此，更好的做法是将master合并回develop或release？master branch上存在release标记Developop是受保护的分支。我想说，最好的做法是不要使用git流，因为git流试图使用非循环有向图来实现不同的目的。我能给出的唯一理由是，您应该能够始终从

git descripe

命令中看到提交的正确版本。