“ git checkout HEAD”如何以及為什么導致“ --theirs”和“ --ours”不同的結果？

Question

當我在中間rebase的沖突，我想看到將被提起的變化--ours ， --theirs和HEAD 。

所以，我檢查了所有這些（從字面上看）：

git checkout --ours <new_file>

vim <new_file>

...我檢查文件...

git checkout --theirs <new_file>

vim <new_file>

...我檢查文件...

git checkout HEAD <new_file>

vim <new_file>

...我檢查文件...

然后，我回去檢查theirs和ours ：

git checkout --theirs <new-file>

vim <new-file>

由於某些原因，當我簽出HEAD時，-- --theirs和--ours都符合該版本。 我知道git checkout應該會更改工作目錄和索引，但是即使我檢出- --theirs 又仍然像HEAD版本一樣。

這是怎么/為什么？ 有沒有辦法找回我原來的- --theirs和- --ours版本？ 謝謝。

Answer 1

Git使用--ours和--theirs參數對git checkout進行選擇，以提取要提取的沖突合並的哪一側。 更准確地說，當您有一個沖突的合並時，對於每個沖突的（“未合並”）路徑，git的索引/分段區域中的該路徑都有三個¹條目。 Git對這些進行編號：

:1: path基於合並的版本
:2: path的“我們的”版本
:3: path的“其”版本

注意:0: path “丟失”，在這里：插槽0保留用於解析（合並）的路徑。

當您執行git checkout HEAD path ，git認為您正在解決沖突。 它放棄了其他三個版本，並填充了插槽0。實際上，如果將HEAD替換為任何分支或“樹狀”說明符（例如git checkout branch1 path ），它也會認為您正在解決沖突。

幸運的是，有一種方法可以告訴git（重新）創建合並沖突，重新填充其他三個插槽（並放棄插槽0中的版本）：

$ git checkout -m path

Git的合並嘗試照常結束在您的工作目錄中。

一個輕微的缺點是<<<<等之后的符號會丟失（您可以實際提供它們，因為它們來自特殊的git環境變量，但我認為這很少值得打擾）。 [編輯以添加注釋：我指的是標記后添加的額外信息，例如：

<<<<<<< HEAD:more information here

我所看到的就是“這里的更多信息”。]

---

¹更准確地說， 最多三個條目：如果在某些合並的提交中刪除了文件，則明顯的條目將被忽略。