Github 顯示主分支和 PR 分支之間的差異不正確

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 拉入/變基到我當前的分支並在我的文本編輯器中處理合並沖突是完全沒問題的。 我問這個是因為我正在和剛接觸 git 的學生一起工作，特別是對 group git 非常陌生，我想知道為什么會發生這種意外行為，以便我可以向他們解釋。

如果您想查看 repo 本身，請看這里。

謝謝！

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分支-這也叫j/difference在你的倉庫，因此得名origin/h/difference在我的，雖然我不知道，直到我拿來refs/pull/2/head從0bb0d7f是提交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添加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

我得到了一個小欄，上面寫着“這個分支有必須解決的沖突”。

如果你現在合並到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 的指針，並不“擁有”任何更改； 並且每次提交都包含整個存儲庫在某個時間點的快照。

為了創建雙向差異，我們需要選擇其中兩個快照進行比較； 對於這個提議的合並，我們可以看到幾個這樣的比較：

1. 合並前后的main ：將f與建議的j版本進行比較
2. 合並前的main和feature ：直接比較f和i
3. feature中尚未包含在main的更改：將c （可從兩個分支訪問的最后一次提交）與i
4. main feature中尚未包含的更改：將c與i進行比較

您已經假設 Github 會向您顯示選項 1。由於合並會產生沖突，因此建議的j版本必須包含這些的一些表示，就好像您創建了一個沒有解決它們的提交一樣。

Github 實際向您展示的是選項 3：無論main上發生了什么，它只顯示對feature所做的更改。 當您對feature有多個提交時，您可以最清楚地看到這一點：它將允許您將視圖過濾為單個提交，如果與建議的合並提交j進行比較，這將沒有多大意義。

他們選擇這種方式可能有幾個原因：

• 從歷史上看，“拉取請求”是通過電子郵件發送的一系列補丁。 發送電子郵件的人不知道收件人的main分支是什么樣的。
• 查看更改時，您可以針對特定行號添加內嵌注釋。 如果第 100 行變成了第 150 行，因為對main的非沖突更改在文件上方添加了 50 行，則必須計算注釋的新位置。
• 如果存在沖突，就像在這種情況下一樣，提交j的提議版本必須包含針對這些沖突的某種標記。 僅將其視為雙向差異會導致注釋混亂，例如，您正在添加代碼<<<<<<<<<<<<<<<<<<<<<< 。 更自定義的 UI 是可能的，但設計起來很棘手，因此易於理解。

某些 UI 將允許您在三窗格視圖中直觀地解決沖突，這實際上塞滿了大量信息：外部面板顯示了上面的比較 3 和 4（對兩個分支中的每一個所做的更改），而中心面板顯示比較 1（當前嘗試合並它們）。 這些視圖的一個重要方面是中心面板是交互式的 - 它顯示您解決沖突的結果，而不僅僅是它們的文本表示。