Question

我正在努力了解这里发生了什么，因为这让我感到沮丧。

假设我有两个长寿的分支。 () - Master和[] - Develop。我的回购的当前状态如下所示：

() <-- Master \ \ []--[]--[] <--Develop

我介绍了一个{} - hotfix主分支，其中包含需要进入Master和Develop的更改。

()--{} <-- Hotfix (needs to go into both Master & Develop) \ \ []--[]--[] <--Develop

我通过单独的Pull请求将修补程序合并到Master和Develop中。

   _ _ _ _ _
  /         \
 ()----{}---() <-- Master /w hotfix changes
   \    \_ _ _ _ _
    \             \
     []--[]--[]----[] <--Develop /w hotfix changes

此时我注意到VSTS'拉请求差异化UI中的两件事：

如果我创建还有另一个拉动请求修补程序进入Master或Develop（回想一下，两个长期分支已包含来自先前PR的修补程序更改），基于Web的差异UI仍会显示修补程序和Master或Develop之间的差异。
如果我创建一个pull into for develop into master，它会显示修补程序中包含的更改的差异（但这些更改已经在Master和Develop中）。

这里发生了什么？

Answer 1

主要观点是 VSTS如何为快进合并完成PR 。

假设有两个分支（branch1和branch2），其中包含以下提交历史记录：

…---A   branch1
     \
      B  branch2

如果您以默认方式（快进）将branch2合并到branch1，例如直接执行git merge branch2命令，branch1和branch2将指向同一个提交B，如下所示：

…---A---B   branch1, branch2

但是对于VSTS，它完成了一个没有快进的PR，作为命令 git merge --no-ff 。因此，即使是快速合并，也会创建合并提交。

因此，如果您创建PR以将branch2合并到branch1（或使用命令git merge branch2 --no-ff），则提交历史记录将为：

…---A---C   branch1
     \ /
      B   branch2

如果您在VSTS中创建PR以将branch1合并回branch2（实际上这是不必要的），那么它允许您从{{1}提交C以来创建PR }}不在branch1上。

现在回到你的情况，提交历史原文如下：

branch2

当您首次创建两个拉取请求以将H1 hotfix / M1 master \ D1---D2---D3 develop合并到hotfix和master分别合并到hotfix时，在完成两个拉取请求后，提交历史记录看起来像：

develop

因此，如果您创建另一个PR以将M1-------M2 master \ / \---H1---------- hotfix \ \ D1---D2---D3---D4 develop / master分支合并到develop，则VSTS将允许您创建自hotfix / master以来的PR branch和develop分支指向不同的提交。但实际上没有必要将这些变化合并。

你创建一个PR来合并hotfix分支到develop分支，它不仅显示提交master，D1和D2的差异，还会显示diff提交D3和M2（即使它们包含来自D4分支的相同更改），因为它们是不同的提交。

BTW：

根据您的工作流程，hotfix是主要分支，所有工作都是在master分支上开发的。准备就绪后，将develop分支合并到develop分支。
对于错误修复，它需要从master分支分支hotfix分支。但是当修复master分支上的错误时，您最好将hotfix合并到hotfix分支中，然后将develop分支合并到develop分支中即可。这可以使历史更清晰。

我的VSTS拉取请求在两个分支不存在时显示差异

1 个答案: