Git恢復合併提交，丟失了一些文件

Question

因此，我錯誤地合併了分支release並推送。 然後恢復它，並提交合並提交，並且一直運行良好。

當試圖合併release到master時，問題出現，注意到一些丟失的文件和奇怪的更改。當我的master分支上發生了錯誤的合併時，問題變得更加令人恐懼。我回頭看看恢復合併提交(W1)，我看到所有這些文件在相反文件刪除提交時丟失的文件。

牢記的feature分支將是在master反正合並，我對逆向思維上衍合-i從master提交(W1)並繼續就這樣完成合並無反向承諾。

您是否認爲有更好的解決方案？

謝謝大家！ :)

編輯

首先，感謝您的關注和響應！我在圖片上添加了一些內容以更好地解釋情況。
實際上我們不再在乎圖片中的release分支，它隻影響幾個文件，並且可以出現在master上，沒有任何重大問題。在master之間創建release和feature之間的文件添加和修改。

我試圖重新發布主分支，發佈合併後(M2)刪除(W1)。我知道我們放棄了一些release的歷史，但我認爲這是一個更好的解決方案來「保存」實際發佈的代碼，如果有必要，我們可以從它開始回購。 有1000次提交重投，有些衝突正在播種。我正在糾正與每個文件的最新正確版本的每個明顯衝突。

EDIT 2

最後，我們重建基礎的master分支，然後在該分支的頂部所施加的差異，像「假底墊」，這樣的變化是顯而易見的和可變的。

Answer 1

UPDATE：根據您的更新問題

，我明白爲什麼文件缺失發生。這對我來說似乎是一種不尋常的情況組合。最有趣的一點是，合併的恢復比初看起來更加危險。撤銷合併（通過重置清除歷史記錄之前將其從歷史記錄中清除）是典型的過程，並且可以避免這種問題 - 如果問題在推送之前被捕獲。但這在這裏和現在沒有太大的幫助。

雖然有所澄清，但我仍建議您不要對您提出的歷史編輯進行修改，並且我所有關於該修改的建議都包含在我的原始答案中。請記住，如果您通過修改release提交，release將仍然具有原始提交，並且您將有一個奇怪的，分裂的歷史記錄容易在某些合併操作中發生衝突（因爲重複的提交執行相同的操作） 。

如果您想將M1的所有更改恢復到歷史記錄中，可以通過回覆W1來減少頭痛。你仍然可能會遇到一些衝突，但是從一開始就簡單得多。不會造成上游發生重組問題;並且讓您在路上看到更少的衝突合併。

---

這聽起來像你正在考慮編輯發佈分支的歷史。爲了短期的原因（需要「上游調整」resoultion）和長期原因（發佈部門不再記錄發佈的內容），我建議不要這樣做。當然，我可能誤會你提出什麼，讓我們得到一個共同的出發點：

您目前有類似

O --- x --- x --- x --- M2 <--(master) 
\  \    /
    \  x --- M1 --- W1 <--(release) 
    \  /
    A ----- B --- C --- D <--(feature) 

其中M1是的feature一個錯誤的合併成release，W1恢復M1和M2是release最終合併爲master。

據我所知，所有這一切都被推動，其中一些反映在您的發佈版本的歷史中，並且「問題」提交也已經是master的共享歷史的一部分。所以如果是我，我會認爲幾乎所有這些都是「石頭寫的」。

如果你最終決定使用變基「修理」的發佈分支，兩件事情要考慮：

1）這將是最好的發佈分支歷史刪除M1和W1，使至少它的結果樹是你發佈的東西的正確反映。 （我認識到，最終從M1工作將被重新推出，但是這不是你發佈的內容。）

2）做到了這一點，你不得不重做M2合併使用新release（創建M2'） ref，然後rebasease master，以及從master分支的所有其他從M2到M2'的分支。如果這是一個積極的回購，它可以迅速蜘蛛網。

這就是爲什麼我不會。那麼你還能做什麼？

這聽起來像release出來看，因爲它應該，所以這是我不清楚爲什麼這會對master任何不良影響，直到您嘗試合併feature。畢竟，如果在W1中刪除了一個文件，那麼該文件必須已被添加（從release的角度）M1，因此在將其應用於master時通常不會有任何淨變化。如果master即使不包含feature也會搞砸，那麼可能需要更多信息來理解爲什麼（以及如何處理它）。

（或者OTOH，如果feature已已經在你開始嘗試合併release掌握時間合併master - 這可以解釋爲什麼合併看起來像一個爛攤子 - 那麼這將需要不同的分辨率是什麼我以下建議。）

但是，如果當它從問題聽起來，你沒有尚未合併feature，那麼當你做嘗試合併feature到master，我希望git的思考A和B （最終添加文件）已通過M1應用。 （W1隨後發生的變化，然後發生撤消它，但git並不在乎）。

我想你需要的是新的承諾，做A和B做了什麼。你可以通過相對得到，通過將feature重新編號爲M2（或稍後在master）稍有頭痛。問題是，如果你告訴rebase，master是你的上游，它將跳過A和B（因爲那些可從master到達）。所以你必須強制上游承諾O。

所以你可以看看了SHA價值O，或穿上它一個標籤（比如feature-root），然後

git rebase --onto master feature-root feature 

產生

      A' --- B' --- C' --- D' <--(feature) 
         /
O --- x --- x --- x --- M2 <--(master) 
\  \    /
    \  x --- M1 --- W1 <--(release) 
    \  /
    A ----- B --- C --- D 

所以C和D並不重要（gc將最終回收它們），A和B（和M1）被遺留在歷史中（避免最有問題的逆境並且只有共享feature ref的用戶需要擔心上游基準恢復。