Question

当前，我们在分支策略中使用GitFlow方法。但是，我们遇到了以下情况。我们创建了一个发布分支。有几个错误需要在发布分支上进行修复。同时，由于开发分支继续进行开发，因此还有更多的提交。在我们准备发布时，发布分支已合并到master。现在剩下要做的就是将发布分支合并回develop。当我尝试提高PR时，它没有什么区别，因为在发布分支上完成修复后（从时间轴角度），对同一文件的更新不同。

我可以选择某些更改或创建差异并在另一个分支中进行修补，然后再次提高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

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

如果在master上创建，则应将master合并回develop
如果在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，请手动进行合并，或者仅接受稍有差异并继续。

Git分支策略问题

2 个答案: