當通過保留當前分支版本來解決 git 合并沖突時，運行時不會列出git status任何檔案，因為沒有檔案被更改。
當然，如果選擇其他分支版本來解決沖突，則會列出更改。
有沒有辦法在解決之后（以及提交之前）查看參與合并沖突的檔案，而不管更改如何？
示范
以下是我所談論的內容的完整復制：
假設我們有：
- 一個
master分支，檔案名為t.txt. - 一個
dev是被分支出來的分支master（因此dev也有t.txt）。
現在，讓我們創建一個沖突：
$ git checkout dev
$ echo test1 > t.txt
$ git commit -am "test1"
$ git checkout master
$ echo test12 > t.txt
$ git commit -am "test12"
$ git merge dev
最后一行的輸出是：
Auto-merging t.txt
CONFLICT (content): Merge conflict in t.txt
Automatic merge failed; fix conflicts and then commit the result.
現在，讓我們編輯檔案以解決沖突：
編輯前：
$ nano t.txt
<<<<<<< HEAD
test1
=======
test12
>>>>>>> dev
讓我們通過dev在編輯器中洗掉s 版本來解決沖突。因此，編輯后：
$ cat t.txt
test1
現在：
$ git add .
$ git status
On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
但是，如果不是通過保留master's 版本來解決沖突，我們將使用dev's 版本，如下所示：
$ cat t.txt
test12
...然后將列出更改的檔案：
$ git add .
$ git status
On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Changes to be committed:
modified: t.txt
所以，回到我的問題，無論如何，我想以某種方式列出t.txt它是已解決合并沖突的一部分。可以做到嗎？
uj5u.com熱心網友回復：
所以，回到我的問題，我想以某種方式列出 t.txt 無論如何它是已解決合并沖突的一部分[甚至在第一次提交結果之前]。可以做到嗎？
Git 沒有用于合并沖突解決方案的可重做“撤消”，但幸運的是，如果您對工程師的帽子感到滿意，則很容易在不傷害任何東西的情況下查看之前的內容：
scratch=`mktemp -d`
git worktree add -d $scratch @
cd $scratch
git merge MERGE_HEAD # with whatever options you used before
并且您重新創建了原始的沖突狀態。cd 回來，git worktree remove $scratch當你完成查找時。
我能想到的唯一一種無法重新創建的情況是，如果您使用 rerere on 運行并且自解決以來您手動運行 rerere，并且您想看看如果您沒有這樣做會產生什么結果，我認為沒有人教 Git 如何處理這個問題。
編輯：順便說一句，如果結帳足夠痛苦，以至于您愿意稍微跳舞以避免它，Git 可以做的事情稱為“最小結帳合并”，它只檢查需要某種合并解析度的檔案. 它......非常快。谷歌沒有將我的答案排名非常高，所以這里有一個鏈接，而且......好吧，這幾乎和作業樹解決方案一樣簡單。
git clone -ns . `mktemp -d`
cd $_
git reset -q
git merge $(git -C $OLDPWD rev-parse MERGE_HEAD)
git ls-files -u | uniq
你有你的沖突檔案串列。該臨時克隆很可能很小，您可以放棄它并讓系統隨時清除它，但是如果您感到挑剔，則可以cd -; rm -rf $OLDPWD在完成后將其洗掉。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/341649.html