當我`gitpull--rebase`得到一個沖突時，我如何`git顯示`對方的提交？

這里沒有列出的是當前合并沖突的另一半。我知道我的提交是def456，但它沒有告訴我任何關于別人提交的資訊，我的提交與之沖突。這非常令人沮喪，因為我無法git show blah，以查看其他作者單獨修改的內容，從而了解他們修改的語意，然后將其與我的合并。

目前，我去登錄Web UI（如github），查看最近的提交串列，并找到已經合并的abc123之后的第一個提交，但一定有一個簡單的方法可以從CLI中獲得這個。

是否有？

uj5u.com熱心網友回復：

正如Enrico Campidoglio所指出的，要找到你的沖突的原始來源是很困難的。 不過，我認為值得對why進行擴展。 馬特的評論提到了:2和:3語法，用于查看Git索引中的檔案副本，就其本身而言是正確的，但這可能還不夠：

最后一個命令完成（1個命令完成）。
  pick def456 做一些改變 blah blah blah

...
def456：這是我的提交，它與......別的東西有沖突

。

something else是Git正在構建的提交，根據rebation中的內容，它往往是你自己的提交中被復制的一個。 所以這里的檔案可以有用：這就是即時沖突的來源。 這可能就夠了。 但是原始沖突來自哪里？

重建，第一部分

讓我們看看一個典型的重建操作，并給每個提交一個簡單的單字母的假ID名，這樣他們就容易被談論。 我們從：

...--E--F <-- main, origin/main
         
          G--H--I <-- my-new-feature (HEAD)

或者--如果你還沒有給自己起好的分支名稱，試圖讓自己今天不迷惑明天不迷惑的話--或許：

...--E--F <-- origin/main
         
          G--H--I <-- main (HEAD)

也就是說，你做了三個自己的提交，G，H，和I。 這三個提交是從一個提交序列的頂端延伸出來的，這個提交序列曾經和/或仍然被您的倉庫中的某個分支名稱所發現：特別是提交F，它可能只被一個remote-tracking name如origin/main所發現，或者如果您在一個名為my-new-feature的分支中作業，可能被您的分支名稱main所發現。

您運行了git fetch和git rebase。 你可能是通過在命令列上輸入git pull來完成的，它運行了git fetch，然后是第二個命令，在這種情況下，你告訴它運行rebase作為它的第二個命令。 無論哪種方式，git fetch都獲得了一些新的提交；我將在這里畫上兩個，并更新origin/main以指向這兩個中的最后一個：

J--K--K

 J--K <-- origin/main
         /
...--E--F
         
          G--H--I <-- my-new-feature (HEAD)

我完全沒有畫出main這個名字，因為我們不需要它；如果你過去（現在也是）將你的新分支稱為main，那就是找到提交I的名字，但是無論如何，我們有一個找到提交I的名字和一個找到提交K的名字，而這就是我們感興趣的兩個名字。
現在我們執行第二條命令，git pull將運行，即git rebase。 rebase命令的作業原理是：復制一些現有的提交，這些提交還不錯，但由于某些原因，還沒有達到要求，它們被復制到新的和改進的提交中。 改進可能包括：
 

 
改變 "基礎 "的提交。
改變 "基礎 "提交（因此被稱為rebase）；和/或
以某種方式改變存盤的快照
。

雖然存盤快照是Git存在的原因，但人類傾向于關心的是存盤快照對之間的改變。 重置操作產生了新的和改進的提交，使兩對之間的變化與原來的兩對之間的變化相匹配：
 


(F, G)是你分支上的一對提交，有一些改動。
(G, H)是你分支上的一對提交，有一些改動。
(H, I)是你的分支上的一對提交，并有一些改動。

Git 不需要直接列出這些提交對：它只是列出了第二個提交的哈希ID。 每個提交對中的第一個提交自動地只是第二個提交的父級提交，因為這些提交對（必然）是父子對。
因此git rebase列出了要復制的三個提交的哈希ID。G、H和I。 然后git rebase：

進入detached HEAD模式：
 J--K <-- origin/main, HEAD
         /
...--E--F
         
          G--H--I <-- my-new-feature


開始運行git cherry-pick，一次一個櫻桃（一個提交）：
git cherry-pick <hash-of-G>
git cherry-pick <hash-of-H>
git cherry-pick <hash-of-I>



每一個cherry-pick操作都是一次合并，某種意義上。 所以每一個操作都可能因為合并沖突而失敗。 然而，唯一有明確合并沖突的是第一個。 讓我們來探討一下原因。
 

Cherry-pick vs merge
在一個標準的git merge中，我們從兩個在過去共享一些提交的分支開始：

 o--o--o--L <-- my-branch (head)
         /
...--o--B
         
          o--o--o--R <-- their-branch

我們在my-branch分支上，正如HEAD被連接到my-branch所表明的那樣。 提交L（左側或本地或--我們的提交）是current commit，它有一些快照。 另一個---theirs提交，在右側或遠程，是R提交。 共同的起點--合并基礎--是提交B。 提交B和R也各自有一些快照。
Git將對B和L的提交進行比較（如git diff --find-renames），以找出我們改變了什么：我們碰了哪些檔案？ 我們增加和/或洗掉了哪些行？ 然后，Git將對B和R進行差分，以獲得關于他們改變了什么的相同資訊：他們碰了哪些檔案，他們增加或洗掉了哪些行？
Git現在可以合并這些更改。 當我們觸碰了一個檔案，而他們沒有，這很簡單：采取我們的改變。 當他們碰了一個檔案，而我們沒有，這也很簡單：接受他們的改動。 當我們都觸碰了相同的檔案，那就更難了，但Git可以合并這些修改，并且可以知道我們是否觸碰了檔案的相同行，因為我們都是從B中的相同檔案開始的，所以如果我們觸碰了B中檔案的第17行，而他們只觸碰了第42行，這些修改不會相互碰撞。
（Git在這里是非常注重行的。 更改是以逐行為基礎的，并以這種方式合并。 這不一定是合并引擎的作業方式，但它是Git的引擎的作業方式。 從技術上講，Git有一個可插拔的合并架構，但在所有你可以插入的合并引擎中，所有的作業方式都是這樣的。
如果我們有一個沖突，我們可以很容易地看到它到底來自哪里。 檔案的合并基礎版本在索引槽1中，所以git show :1:file.ext顯示了該檔案的版本。 我們的檔案版本在索引槽2中（也在名稱為HEAD的提交中），所以git show :2:file.ext或git show HEAD:file.ext顯示了檔案的that版本。 他們的檔案版本在索引槽3（也在臨時名稱MERGE_HEAD找到的提交中），所以git show :3:file.ext或git show MERGE_HEAD:file.ext顯示了他們的檔案版本。
一旦合并完成，Git 就會做一個合并提交，或者讓我們做一個，如果我們必須先解決沖突的話，而且新的合并提交本身也有一個所有檔案的（單一）快照。 根據定義，這就是合并的正確結果。 在有沖突的地方，Git讓我們解決它們，所以我們的解決方案是正確的。 我們可以像這樣畫出我們的合并：
 

 o--o--o--L
         /          
...--o--B M <-- my-branch (HEAD)
                   /
          o-o-o-R <-- their-branch

新的合并提交M的唯一特別之處在于，它不是只有一個父級，而是有兩個：第一個父級是L，就是剛才我們的提交，而第二個父級是R。 從L到M的差異是合并R的解決結果，而從R到M的差異則是合并L的解決結果。 這里的決議是在提交M的快照中所固有的。
當我們運行git cherry-pick時，情況就不同了：
 o--...--P--C--...
         /
...--o--o--...--L <-- my-branch (HEAD)

我們運行git cherry-pick C來復制C中的改動，即我們想要復制的那個。 但是，什么是提交C中的變化？提交持有快照，而不是變化。
為了找到變化，Git必須找到子提交C的父P。 然后，Git可以在P與C之間運行git diff，以找到變化。 Git也應該包括--find-renames，以防提交C重命名一個檔案。 Git現在必須結合這些變化和...什么？ 提交L，像C一樣，只是持有一個snapshot。
Git 可以 嘗試以git diff的方式應用這些變化，早期版本的Git就是這樣做的。 事實上，直到最近，標準的git rebase運行git format-patch，將提交的內容變成適合通過電子郵件發送的補丁，然后在產生的電子郵件檔案上運行git am來應用它們。 這就是git-rebase-am 后端的git rebase，它仍然存在，并且至今仍可使用。 它有一些缺陷：例如，它不檢測重命名，而且它不能復制一個空變更集的提交。2因此，從Git 2.26開始，它不再是rebase的默認值。 無論如何，它已經很久沒有在git cherry-pick中使用了。
在任何情況下，為了可靠地檢測沖突，cherry-pick所做的是將提交P作為合并的合并基礎。 也就是說，cherry-pick代碼以P作為偽造的合并基礎來運行合并。 提交L，本地或--我們的提交，一如既往的--我們的，所以對于Git發現的檔案在P和L中存在的任何變化，Git將保留我們的 "變化"，也就是說，保持檔案在L的樣子。 然后，Git會將添加到這些 "變化"（這讓我們得到了我們的L副本）中的任何變化P-vs-C diff。
因此，當我們運行git cherry-pick C--出于任何原因--所涉及的三個提交是提交C本身當然作為--theirs，C的父P作為合并基礎，和我們自己的當前提交作為--ours一樣。 如果我們遇到沖突，我們大概知道所有關于我們的檔案--畢竟這只是我們的檔案--我們可以查看P和C以及它們之間的變化，看看它們改變了什么以及為什么。
1這里有一些惱人的松鼠性（squirrelly-ness？內置的拼寫檢查甚至不喜歡普通的squirrelly，雖然事實上是一個詞）圍繞著重命名。 命名為file.ext的檔案可能在一個或兩個甚至所有三個提交中擁有一個不同的名字，但仍然是同一個檔案。
2 git am 或 git apply 后端理論上可以在git rebase理論上可以檢測到沖突的情況下忽略。 我不確定這種理論上的遺漏是否有任何實際的區別。 因為Git在其差異和合并引擎中是相當一致的，我不確定是否有辦法觸發這種情況。 當git am或git apply確實檢測到沖突并 "回落 "到3路合并的技巧時，其結果與使用cherry-pick時相同。 除此之外，git apply最近被教導要注意到index行并提前使用3路合并，所以這也可能消除任何理論上的差異。 然而，這將取決于您的特定Git版本，因為2.20之前的Git版本不積極使用index行。
重設，第二部分當我們運行git cherry-pick時，所有關于如何處理cherry-pick操作的東西都很好，但是在git rebase期間，Git是運行cherry-pick的人，一次又一次：
 J--K <-- origin/main, HEAD
         /
...--E--F
         
          G--H--I <-- my-new-feature

Git 運行 git cherry-pick hash-of-G 來復制提交 G 到一個新的和改進的提交，我們稱之為 G'。

知道了cherry-pick的作業原理，以及G是我們新功能的第一個提交，我們就可以在出現沖突時查看提交K的檔案：那是他們的檔案。 我們知道，"他們 "的修改--父母對子女--實際上是我們在提交G的修改。 我們可以利用這一知識來解決任何沖突，并允許Git制作新的副本G'：

G' <-- HEAD
              /
          J--K <-- origin/main
         /
...--E--F
         
          G--H--I <-- my-new-feature

但是現在，Git 運行 git cherry-pick hash-of-H 來復制提交 H 到一個新的和改進的提交，我們稱之為 H'。 如果一切順利的話，結果將是這樣的：

G'-H' <-- HEAD / J--K <-- origin/main / ...--E--F G--H--I <-- my-new-feature

此時，Git將運行git cherry-pick hash-of-I來復制提交I到一個新的和改進的I'。 如果這有一個沖突，我們仍然處于我們上面畫的狀態。 ---我們的提交是提交H'：我們對H的拷貝。 --theirs的提交是I：我們從H到I的改變。 沖突發生在--我們的提交中的某個檔案，H'，與--theirs提交中的某個檔案，I，相比之下，提交H中的某個檔案。這三個提交都是我們的！

這里的問題是，我們的提交H'中的沖突部分，與合并基礎提交H的差異，實際上來自提交J或K。 這就是關鍵的認識。 沒有它，Enrico Campidoglio的回答就沒有意義了。 如果H-vs-H'中的某一行與我們自己的H-vs-I的修改相沖突，我們必須在J和/或K的提交中找到正確的一行，以了解他們為什么要做修改。

僅僅使用H'中的行號的一個問題是，它們可能與J和/或K中的行號不符。 我們真正需要的是在J和/或K中存在的行號，而且是在G和H被Git匯入之前的行號。

我們想看看--onto目標中的提交--這里是origin/main或提交K--不在原始源分支中：這里是提交F，它可能沒有名字。 Git的reflogs可以提供幫助，因為origin/main@{1}將包含提交F的哈希ID。 或者，如果我們使用自己的分支名，并且周圍有一個分支名main，指向提交F，我們可以使用它。 運行：

git log origin/main@{1}...origin/main

git log main...origin/main

 G'-H'-I' <-- my-new-feature (HEAD)
              /
          J--K <-- origin/main
         /
...--E--F
         
          G--H--I ???

# 'U' means unmerged。
git diff --diff-filter=U --name-only

1 │ <<<<<<< HEAD
2 │ 這里有一些內容
3 │ =======
4 │ 這里有一些不同的內容
5 │ >>>>>>>def456 (你的提交)

git log --oneline -L1,2:path/to/conflicting/file abc123

git merge-base main abc123