好吧，我有4個分支鏡像。其中2個是主要分支機構。如何解決推力災難後的拉取請求？
我想重新綁定一個我的功能分支與主分支。所以我在運行rebase命令後做了這個
git push --force
雖然我的功能是工作分支。
這導致的問題，推到所有分支機構，因爲我的混帳配置設置是「匹配」
尚未長久以來這已經發生了，所以我們能夠恢復到原來的位置所有分支。
但是，我現在注意到pull請求現在顯示的提交比他們應該更多。我相信這是災難的副作用。如何解決這些拉請求？
如果您確實已將存儲庫分支恢復到災難發生前的狀態，那麼任何在災難期間未做任何拉動的應用程序都不應該有任何問題進行新的拉動。在發生災難時，一些開發者可能會從存儲庫中提取強制材料。那麼當他們從固定存儲庫中取出時他們將再次遇到問題。
在這種情況下要做的事是避免git pull命令。重寫的歷史會導致重新融化，並且會因不必要的衝突而變得不合時宜。
每個人都應該做一個git fetch來拿起存儲庫資料，而不用對他們的工作副本做任何事情，然後適當地處理這種情況。
假設我在一個名爲master的分支上（不失一般性）。我做了一個git fetch（因爲我被告知上游有歷史重寫），然後輸入git checkout以瞭解損壞情況。我看到一條消息，如：
您的分支和起源/主分支已分叉，並有17和25不同的提交，
好的。所以這意味着上游歷史已經從第17次提交（從我們當地master的p.o.v.）開始重寫。現在，假設我碰巧知道master上的四次提交是我的新的本地提交。當然，我知道這一點，因爲當我做一個git log時，我知道我的是什麼！ （另外，我正好要記住，這帶來了在這個爛攤子git fetch之前，Git會告訴我，我的master領先的origin/master 4次的提交。）
如果這是別人的亂七八糟的，我沒不知道承諾保留什麼，我會比較
git log和git log origin/master以查看重複開始的位置，並假定master上比重複提交更新的任何內容都是需要保留的寶貴更改。
我所關心的是保留這四個變化。我想要做的是使master看起來像改寫origin/master,加我的四個變化。
有多種方法可以做到這一點。這裏是一個非常簡單的：
git rebase HEAD~4 --onto origin/master
完成！我們拿到了前四名提交，並將它們遷移到origin/master，並將結果代替了主分支。 （順便說一句，我懷疑--onto origin/master的論點是多餘的，因爲我們在master和origin/master是它的上游！所以它可以像git rebase HEAD~4一樣簡單。「把四個提交到救生艇，並且前往非沉沒船！」）
注意，如果我們做了一個git pull --rebase，那麼它會做等價的：
git fetch # master and upstream diverge: 17 versus 25
git rebase # all 17 commits are being rebased over top of the upstream 25, OOPS!
隨着rebase HEAD~4，我們限制了底墊的範圍只櫻桃採摘那些我們知道是提交那些是我們需要重新設計的承諾，而不是上游25 a中複製的剩餘承諾nd會導致合併問題。剩下的13個被放棄。我們的四項更改通過origin/master進行重播，併成爲新的master。
請注意，有時天真的rebase 可以工作！例如，假設重寫的25次提交的歷史記錄實際上沒有對文件內容進行任何更改，而只是提交消息，作者和時間戳。在這種情況下，git可以解決這個問題。例如，隨着審查工具Gerrit的發生，這種情況一直在發生。當您提交的Gerrit更改合併後，它們仍在您的本地回購中。當你做一個
git pull時，你可以引入完全相同的提交的合併版本，但在不同的哈希下。 Git發現你已經在本地提交了相同的提交，並且它們在rebase中消失了。