我试图了解这里发生的事情,因为这让我绊倒了。
假设我有两个长寿的分支。 () - Master
和 [] - Develop
.我的 repo 的当前状态如下所示:() <-- Master
\
\
[]--[]--[] <--Develop
我介绍一个{} - hotfix
将 master 分支与需要进入 Master 和 Develop 的更改分开。
()--{} <-- Hotfix (needs to go into both Master & Develop)
\
\
[]--[]--[] <--Develop
我通过单独的 pull 请求将修补程序 merge 到 Master 和 Develop 中。
_ _ _ _ _
/ \
()----{}---() <-- Master /w hotfix changes
\ \_ _ _ _ _
\ \
[]--[]--[]----[] <--Develop /w hotfix changes
在这一点上,我注意到 VSTS 的 pull request diffing UI 中有两件事:
这里发生了什么?
最佳答案
要点是 VSTS 如何为快进 merge 完成 PR .
假设有两个分支( branch1
和 branch2
)具有以下提交历史:
…---A branch1
\
B branch2
如果 merge
branch2
进入 branch1
默认方式(快进),例如通过执行 git merge branch2
直接命令,branch1
和 branch2
将指向相同的提交 B
如下:…---A---B branch1, branch2
但是对于VSTS,它完成了一个没有快进的PR,如命令
git merge --no-ff
.因此,即使是快进 merge ,也会创建 merge 提交。所以如果你创建一个 PR 来 merge
branch2
进入 branch1
(或使用命令 git merge branch2 --no-ff
),提交历史将是:…---A---C branch1
\ /
B branch2
而如果你创建一个 PR 来 merge 回来
branch1
进入 branch2
在VSTS中(实际上这是不必要的),它允许您自提交C
以来创建PR来自 branch1
不在 branch2
.现在回到你的情况,提交历史原始如下:
H1 hotfix
/
M1 master
\
D1---D2---D3 develop
当您第一次创建要 merge 的两个 pull 请求时
hotfix
进入 master
和 hotfix
进入 develop
分别,完成两个 pull 请求后,提交历史看起来像:M1-------M2 master
\ /
\---H1---------- hotfix
\ \
D1---D2---D3---D4 develop
所以如果你创建另一个 PR 来 merge
master
/develop
分支到hotfix
, VSTS 将允许您创建 PR,因为 master
/develop
分支和hotfix
分支指向不同的提交。但实际上没有必要将更改 merge 回来。然后你创建一个 PR 来 merge
develop
分支到master
分支,它不仅显示提交 D1
的差异, D2
和 D3
,但也显示差异提交 M2
和 D4
(即使它们包含来自 hotfix
分支的相同更改),因为它们是不同的提交。顺便说一句:
master
是主分支,所有作品开发于develop
分支。准备好后, merge develop
分支到master
分支。 hotfix
分支来自 master
分支。但是当修复 hotfix
上的错误时分行,你最好 merge hotfix
进入 develop
分支,然后 merge develop
分支到master
分公司 .这样可以更清楚地了解历史。 关于git - 当不存在时,我的 VSTS pull 请求显示两个分支之间的差异,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48564003/