我們可以稱之為“重置請求”，因為我們不是請求將功能分支合并到主分支，而是請求將主分支重置為功能分支。
這樣做的用例是例如清理 git 歷史記錄（沒有任何實際的代碼更改），或者在 fork 之后通過 rebase 從原始 repo 獲取更新到 fork 的 master 分支。您將在單獨的（功能分支）上執行此操作，然后要求掌握“重置請求”。
我知道在共享分支上重寫歷史是一件微妙的事情。我正在考慮為一個小團隊的 repo 這樣做，您可以在其中控制誰在本地提取代碼并傳達應采取的任何步驟以繼續開發。
我正在尋找完成這些事情的標準方法。我找不到與我描述的“重置請求”類似的任何東西（無論是在 Gitlab 上還是在 Github 上）。我現在能看到的唯一方法是強制 push 到 master ；但是，您如何組織對更改的審查？
似乎我錯過了一塊拼圖，除非這些用例不像我想象的那么普遍，所以不要猶豫，糾正我所做的任何不正確的假設。
uj5u.com熱心網友回復：
我很確定答案是否定的，我認為所有主要工具都是如此。（GitHub、Azure DevOps、GitLab、Bitbucket 等）
也許這個功能不存在的兩個主要原因是你提到的兩件事：
這些用例并不像我想象的那么普遍
強制推送共享分支應該是一個罕見的事件。
例如，這個用例是清理 git 歷史記錄（沒有任何實際的代碼更改）......
大多數代碼審查工具都是以檔案為中心的，正如您提到的，即使有一種代碼審查重置機制，實際上也不會有任何檔案需要審查。您仍然需要檢查提交，但如下所述，您可以在包含新代碼的機器上手動進行。
至于你的子問題：
我正在尋找完成這些事情的標準方法。
我不知道重置共享分支的任何（流行）標準，也許是因為圍繞一些不受歡迎且應該很少見的東西創建標準很奇怪。話雖如此：
我首選的重置共享分支的方法是這樣的：
確定您是否真的需要重置，或者恢復是否就足夠了。（通常重置的建議是由于后悔合并某些代碼，在這種情況下，還原也可以撤消它。在您的情況下，還原不適用，因為您希望清理歷史記錄。您必須重置，所以你可以跳過這一步，或者，也許你需要決定是否真的需要重置它。）如果你決定不重置，你就完成了。（還原使用正常的代碼審查程序。）
考慮鎖定共享分支，以便在您重新撰寫它時沒有人向它添加更多內容。
確定要重置的最佳提交。為了撤消令人遺憾的合并，通常您將向后重置為已經在歷史中的提交，也許就在問題之前，但是如果您正在重寫歷史，它很可能根本不會在歷史中。在重寫的情況下，您可能需要在正常審查程序之外審查您的代碼。通常，在包含重寫代碼的某人的機器上，您比較最終狀態并確保唯一的區別是您想要洗掉的任何內容。然后你抽查特定的提交以確保大檔案、密碼等不再存在于歷史記錄中的任何地方。
如果您還沒有，請向您的整個團隊宣布將要重寫一個共享分支，并提供有關如何重寫其 WIP 分支的說明。確保包含要重寫的分支的上一個提示提交 ID，以及要運行的正確命令。也許是這樣的：
git fetch # for each feature branch in progress: git rebase <old-tip-commit> my-feature-branch --onto <shared-branch-name>如果您使用受保護的分支，請暫時授予某人（可能是在其機器上具有重寫歷史記錄的人）強制推送共享分支的權限。
使用安全網強制推送共享分支，特別是如果您沒有按照上面的建議鎖定它：
git push --force-with-lease洗掉臨時權限以強制推送共享分支。
向您的團隊宣布它已經完成并且他們現在可以重寫所有 WIP 分支。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/526281.html