Question

我试图弄清楚为什么“比较文件”中显示的差异实际上不能反映我所做的更改。最近几天似乎是一个新问题；在工作之前，我使用过“比较文件”视图很多次，它始终反映正确的主分支，而现在却没有。

这是我的主分支中当前的内容（一个测试仓库以找出问题所在）：

// this is the entirety of main.js
function addition(a, b) {
  return a + b
}

这是我正在合并的内容：

// this is the entirety of main.js
const difference = (num1, num2) => (
  num1 - num2
);

在我的请求请求中，我希望看到合并冲突，因为我要添加到代码的前几行。我得到的小条写着“该分支有必须解决的冲突”。但是，当我查看比较文件视图时，这就是我看到的：

该视图无法识别出主分支中显然已经存在一个函数：

我无法提出可能如此的原因。与“比较文件”视图比较麻烦吗？可能与我从main分支中删除分支的方式有关吗？

对我来说，这不是什么大问题；将main拉入/重新设置为当前分支，并在文本编辑器中处理合并冲突是完全可以的。我之所以这样问，是因为我正在与git的新手，尤其是对git分组的新手合作，并且我想知道为什么会发生这种意外行为，以便向他们解释。

如果您想查看存储库本身，请here it is。

谢谢！

Answer 1

克隆该存储库，然后获取拉取请求：

$ git clone https://github.com/pmacaluso3/merge_conflicts
Cloning into 'merge_conflicts'...
remote: Enumerating objects: 18, done.
remote: Counting objects: 100% (18/18), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 18 (delta 1), reused 13 (delta 0), pack-reused 0
Unpacking objects: 100% (18/18), done.
$ cd merge_conficts
$ git fetch origin refs/pull/2/head:pr2
From https://github.com/pmacaluso3/merge_conflicts
 * [new ref]         refs/pull/2/head -> pr2

让我们准备好观察提交图。请注意，我在本地分支中使用了名称pr2来引用您的拉取请求＃2，这是您感到困惑的一个：

$ git log --all --decorate --oneline --graph
*   7b4d901 (HEAD -> main, origin/main, origin/HEAD) Merge pull request #3 from pmacaluso3/testing-merge-conflicts
|\  
| *   8941f5a (origin/testing-merge-conflicts) Merge branch 'main' into testing-merge-conflicts
| |\  
| |/  
|/|   
* |   5f144f2 Merge pull request #1 from pmacaluso3/pete/addition
|\ \  
| * | bffd4d1 addition!
|/ /  
| * 660b014 testing
|/  
| * 0bb0d7f (origin/j/difference, pr2) diff
|/  
* 0283a25 initial

所以我们看到在我本地pr2分支中的 commit -在您的存储库中也被命名为j/difference，因此在我的仓库中被命名为origin/h/difference在从GitHub上获取refs/pull/2/head之前，我不知道是提交0bb0d7f，它作为父级提交了0283a25。

如果我们查看0283a25中的内容，就会发现有两个空文件：

$ git show 0283a25 | sed 's/@/ /'
commit 0283a257e0e1802b57dcbbaccc7860a1b2de9dfa
Author: famousPete <pete.macaluso generalassemb.ly>
Date:   Wed Aug 26 13:37:10 2020 -0400

    initial

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..45b983b
--- /dev/null
+++ b/README.md
 @ -0,0 +1 @@
+hi
diff --git a/main.js b/main.js
new file mode 100644
index 0000000..e69de29

因此，您的PR确实确实告诉Git向空的main.js添加三行。

这也是GitHub上的视图显示。

在我的请求请求中，由于要添加到代码的前几行，因此我希望看到合并冲突。

最初建议的合并是0bb0d7f与0283a25。合并成功。 GitHub已经做到了，我们可以得到它：

$ git fetch origin refs/pull/2/merge:temp
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
From https://github.com/pmacaluso3/merge_conflicts
 * [new ref]         refs/pull/2/merge -> temp
$ git log --decorate --oneline --graph temp
*   00e1eb0 (temp) Merge 0bb0d7f5b28f8817564f3acff0ca95a1622ea27d into 0283a257e0e1802b57dcbbaccc7860a1b2de9dfa
|\  
| * 0bb0d7f (origin/j/difference, pr2) diff
|/  
* 0283a25 initial

我得到一个小条，上面写着“该分支有必须解决的冲突”。

如果将 now 合并到main，则是的，将存在合并冲突。但是，除非有人在main的上重新建立此特定提交，否则，任何可能尝试将此提交合并到main的人都将面临合并冲突。如果GitHub可以对main的当前提示进行比较，而不是仅对之前选择的合并基础进行比较，那就太好了。

Answer 2

简单的答案是，您在Github中查看的视图没有显示您认为的视图。

当您在两个分支上进行提交（我将它们称为main和feature）时，您将看到一个类似以下内容的提交图：

            d -- e -- f   <- main
           /
a -- b -- c
           \
            g -- h -- i   <- feature

当您建议将feature合并到main中时，您最终要达到的目标是：

            d -- e -- f
           /           \
a -- b -- c             j  <- main   
           \           /
            g -- h -- i

请注意，main和feature是指向 commits 的指针，并且不“拥有”任何更改；并且每个提交都包含某个时间点整个存储库的快照。

为了创建双向差异，我们需要选择两个快照进行比较；对于此提议的合并，我们可以查看以下几种比较：

main在合并前后：将f与建议的j版本进行比较
main和feature在合并之前：将f与i
feature中尚未进行的main中的更改：将c（两个分支都可以到达的最后一个提交）与i
main中尚未进行的feature中的更改：比较c与i

您已经假设Github将向您显示选项1。由于合并会产生冲突，因此j的拟议版本必须包含这些冲突的某些表示形式，就好像您在未创建的位置创建了一个commit一样。解决它们。

Github实际上向您显示的是选项3：无论main发生了什么，它仅显示在feature 上所做的更改。在feature上有多个提交时，您可以最清楚地看到这一点：它将允许您将视图筛选为单个提交，如果与提议的合并提交{{ 1}}。

他们选择这种方式有几个原因：

从历史上看，“拉取请求”是通过电子邮件发送的一系列补丁。发送电子邮件的人不知道收件人的j分支是什么样子。
查看更改时，可以针对特定的行号添加行内注释。如果第100行成为第150行，因为对main的无冲突更改在文件的上方增加了50行，则必须计算注释的新位置。
如果发生冲突（在这种情况下），则提交main的建议版本将必须包含针对这些冲突的某种标记。仅将其视为双向差异会导致混乱的注释，例如您正在添加代码j。可能会有更多自定义的UI，但是设计起来很棘手，以便于理解。

某些UI允许您在三窗格视图中直观地解决冲突，实际上这是塞满了很多信息的原因：外部面板显示了上面的比较3和4（两个分支中的每一个所做的更改），而中间面板则显示比较1（当前尝试合并它们）。这些视图的重要一点是，中心面板是交互式的-它显示您解决冲突的结果，而不仅仅是它们的文本表示。

Github显示主分支和PR分支之间的差异有误

2 个答案: