我們做了一些不好的事情。合併衝突期間`git stash`
我們在合併衝突期間運行git stash save，現在我們無法恢復我們的工作。
的事情，我們已經試過：
git pull -Xours origin master
git stash apply --index
和：
git pull origin master
git stash save --keep-index "merge conflicts"
git stash apply [email protected]{1}
請幫幫忙！
當您處於衝突狀態（索引和工作目錄）時，您將無法執行git stash - 它會在發生未合併條目時發生錯誤。
確保您確實已經完成了存儲。見git stauts和git stash show
在'git stash'之前，我解決了衝突並繼續使用'git add'。這是我有'git add'我的決議後，我做了進一步的編輯，然後做了'git stash save msg'。所以這確實成功了。 –
@bukzor實際上，我只是在Windows 7上用msysgit 1.8.3進行了測試。如果文件存在衝突（即沒有嘗試解決合併衝突），那麼'git stash save'確實會中止，而沒有存儲衝突的文件。所以***這其實是正確的，這不是假的***。 – 2013-08-10 00:27:39
這個問題似乎是git stash不保存到你試圖在合併分支中的基準輸出。在合併，這是存儲在一個名爲MERGE_HEAD參考。
要修復它，並重新回到以前的狀態，你需要找到的版本（讓我們假裝這是d7a9884a380f81b2fbf002442ee9c9eaf34ff68d）你試圖合併中，並設置MERGE_HEAD它應用藏匿後。
那麼你可以申請藏匿（與--index重新階段這是之前上演的一切），並設置您的MERGE_HEAD：
git stash apply --index
git update-ref MERGE_HEAD d7a9884a380f81b2fbf002442ee9c9eaf34ff68d
儘管上面看起來對我來說是真實的，但我並不完全相信只要設置MERGE_HEAD和去除乾淨就足以恢復合併狀態。如果可能的話，我會避免在衝突期間使用git存儲。 – user1338062
我也會，但在這一點上是後見之明。 – bukzor
鑑於你最後的評論：您可以使用
git stash megre --no-commit <branch>
把指數在「合併」狀態，而不會提交修改
然後用你想要的修改：
，如果你已經工作了您的合併中藏匿：
git reset #to remove the "conflicts" flags
git checkout <initial commit> -- ./ #to revert everything to the previous working state,
git stash apply #apply your changes
，一旦一切都在期望的狀態，git commit
關於bukzor的評論是：居然有一個大git checkout <tree-ish>與git checkout <tree-ish> -- <files>之間的差異。
git checkout <branch>：本表由更新索引，工作樹切換分支，和HEAD以反映指定的分支或提交。
git checkout [-p|--patch] <tree-ish> -- <pathspec>：當<路徑>或--patch給出時，git checkout不會切換分支。它從索引文件或命名爲<的樹形文件>（通常是提交）更新工作樹中的命名路徑。
git checkout <initial commit>確實會丟棄合併信息。
git checkout <initial commit> -- ./（注意額外的-- ./）則保留合併信息，並將每個被跟蹤文件恢復到其狀態<initial commit>。
我今天做了同樣的事情，並採取了一種不同的方法（在試錯之後）返回隱藏之前的狀態，以便繼續解決衝突並完成合並。
首先，在清除目標分支中的部分合並之後，我捕獲了剩餘衝突的文件列表（文本文件或編輯器選項卡）。這只是清空之後非掛起文件的列表，因爲已經解決衝突的文件在存儲之前會被暫存。
$ git status
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: myproject/src/main/java/com/acme/package3/Class3.java
# modified: myproject/src/main/java/com/acme/package3/Class4.java
#
接着，我創建一個補丁，並重置分支返回到預合併狀態：
$ git diff HEAD > ~/merge-with-resolved-conflicts.patch
$ git reset --hard HEAD
然後創建了一個臨時分支（從合併目的地分支來源的），和施加補丁：
$ git checkout -b my-temp-branch
$ git apply ~/merge-with-resolved-conflicts.patch
$ git commit -a -m "Merge with resolved conflicts"
所以我-TEMP分支的HEAD現在包含被合併，包括與衝突的文件解決，剩餘衝突的文件的一切。
然後我切換回原來的分支，再合併，看了看git的狀態
$ git checkout my-branch
$ git merge other-branch
$ git status
的狀態顯示的文件有衝突的完整列表：
# Unmerged paths:
# (use "git add <file>..." to mark resolution)
#
# both modified: myproject/src/main/java/com/acme/package1/Class1.java
# both modified: myproject/src/main/java/com/acme/package2/Class2.java
# both modified: myproject/src/main/java/com/acme/package3/Class3.java
# both modified: myproject/src/main/java/com/acme/package3/Class4.java
#
現在我需要比較這兩個文件列表。第二個列表中的所有文件都已經解析（在本例中爲Class1.java和Class2.java）。因此，對於每個這些文件，我在版本拉從臨時黨支部解決的衝突（如摘櫻桃，但對於單個文件，而不是一個完整的提交）：
$ git checkout my-temp-branch myproject/src/main/java/com/acme/package1/Class1.java
$ git checkout my-temp-branch myproject/src/main/java/com/acme/package2/Class2.java
這樣做之後，我回來了到存儲之前的狀態，所以我可以恢復解決剩餘的衝突並提交合並。（合併衝突期間git的藏匿處彈出）
我的解決辦法擺脫這種的是：
創建並檢出一個新的（本地）分支mytemporarybranch
的Git分支mytemporarybranch & & git結帳mytemporarybranch
提交到這個mytemporarybranch
git的承諾-m 「我凌亂的合併和壁球」
結賬myoriginalbranch
git的結帳myoriginalbranch
合併正確（無剝落流行/應用此一次！）
壁球合併mytemporarybranch到myoriginal分支
混帳合併--squash mytemporarybranch
你真的做了什麼重要的事嗎？ （你是否真的需要恢復隱藏的更改？）你能重置掉嘗試的合併，然後重新執行嗎？ – Cascabel
分別是和否。這些更改由多個合併衝突解決方案組成。 – bukzor
@bukzor：如果您需要更多的一天來解決合併衝突問題，那麼可能需要重新考慮有關分支處理和工作分配（或合併頻率）的策略。如此冗長的合併解決方案畢竟是一個很好的來源，因爲在一次提交中所做的更改量很難找到錯誤 – Grizzly