回滾主服務器原點，無需強制推動

Question

如果禁用了強制推送，是否有任何方法可以將原始主機回滾到先前的提交？ 我有A-> B-> CC是錯誤的提交，順便說一句，B是合並提交。 我希望主服務器原點回到B，但是服務器策略拒絕強制推送。

還有其他方法嗎？

Answer 1

在進入技術選擇之前，我們應該認識到“不推力”政策意味着您無意於做您所描述的事情。 從裁判的歷史中刪除提交內容是“強制推送”功能的關鍵所在（高於常規推送）。 通常，有一個很好的理由使原始存儲庫拒絕強制推送-請參閱git rebase文檔的“從上游恢復數據庫恢復”部分，因為即使您不使用rebase命令，情況也一樣。

還有一些選擇可能足以代替實際刪除C ； 我會回到那。

但是好吧，我們假設無論出於何種原因，您（以及您的團隊/倉庫所有者/負責確定是否可行的任何人）都了解成本，並且仍然希望這樣做，但是無法更改服務器正在執行的策略設置。

還有另一種刪除C嗎？

沒有簡單的。 無論如何，不​​要將原始回購視為遠程。 根據定義，“強制推送”是從遠程引用的歷史記錄中刪除提交的操作。

選項1 ：好吧，我不知道您的原始存儲庫是如何托管的。 服務器軟件是否為您提供了操作存儲庫的選項？ 如果是這樣，那是您最好的選擇。

選項2 ：如果您可以直接訪問原始存儲庫-如果您可以登錄到可以將其視為本地存儲庫的位置，則可以這樣做。 該過程基本上與您在本地進行的過程相同，只是您可能必須首先創建工作樹（因為通常，源將是一個裸倉庫）。 就像是

git worktree add /path/to/create/a/worktree/at master
# cd into the new work tree
git reset --hard HEAD^

然后刪除工作樹（ rm -r ... ）並清理（ git worktree prune ），以使git不必擔心會影響工作樹的推送。

選項3 ：如果您可以直接訪問repo文件，但是由於某種原因無法在它們上運行git，則理論上可以重寫ref本身。 直接在git文件上工作是一個危險的游戲，我並不建議這樣做，但沒人可以說我在考慮選項時並不徹底。

除非您對git有足夠的了解以自行解決此問題，否則執行此操作可能不是一個好主意，因此我將繼續...

選項4 ：我猜您可以替換整個倉庫。 我們真的在這里跌入谷底。

那如果我不能（或決定不刪除） C怎么辦？

您可以revert它。 還原提交M ，將創建一個新的提交W ，該提交“撤消”通過創建M所做的任何更改。 所以

git revert C

會給你

      (origin/master)
            |
A --- B --- C --- !C <--(master)
     /
... X

其中!C具有與B相同的TREE （內容狀態）。 無需--force即可推動此操作。 是否足夠好取決於。

如果C包含敏感數據（密碼，密鑰），那么您可能真的希望它脫離歷史記錄。 我的建議是更改密碼並撤消密鑰。 （即使你刪除C歷史，你能保證沒有人已經復制了嗎？）

如果C包含較大的二進制文件...那是個壞消息。 回購將永遠由由此產生的膨脹負擔。 用重寫的歷史記錄替換存儲庫是唯一真正的解決方法（這使我們回到了上面的選項）。

但是，如果這只是“哎呀”，那么將其從歷史中刪除是可以理解的，但不是必須的。 不希望看到誰的個人C在他們的歷史可以考慮使用git replace為“紙翻面”通過“replace'ing問題!C與B我猜，但它可能不會是值得的。 （請注意， replace僅會造成對歷史更改的錯覺，並且它具有一些記錄在案的怪癖；任何決定使用它的人都應至少閱讀該命令的基本文檔。）