假設我有一個帶有分支主控的存盤庫。我簽出一個分支功能分支并開始研究它。隨著時間的推移，我提出了一個 PR 并在 PR 中推送了 3 個提交。假設 master 分支在此期間進行了 10 次提交，我必須將我的 PR 重新設定為 master 的提示。為此，我遵循以下命令：
git checkout feature-branch
git rebase master
git pull
git push
這些步驟確實推動了我的 PR，但現在我的 PR 包含 3 10 = 13 次提交，這使得審查變得困難。有什么解決辦法嗎？
uj5u.com熱心網友回復：
好的....正如 LightBender 所說，您的配方中有問題，因為您正在合并您試圖重新設定基址的舊分支，因此您保留了舊提交（更不用說我沒有看到您正在拉動更改為您的本地主人）。
您通常應該采取的方式是：
git checkout master
git pull # bring changes from upstream master into your local master
git checkout feature-branch
git rebase master # this is how you move your branch on top of master, keeping it straight
git push -f # assuming that the upstream branch as been set before
# if the upstream branch is not set, then write git push -f origin @ -u
# after that, you can just run git push -f (on subsequent pushes)
現在....你如何擺脫你所處的混亂局面？嗯....我不完全確定這會奏效，但它可能會。假設您剛剛完成了您在那里所做的最后一次拉動：
git checkout feature-branch~ # go to the first parent of that merge.... you should be on top of 3 commits that are straight from main, no merges
# If that is the case, just place your branch over here:
git branch -f feature-branch
git checkout feature-branch
git push -f
如果實際上情況并非如此，那么您將需要親自動手并挑選您希望在分支中擁有的 3 個修訂版......或者 rebase 互動式，這很好，但可能有點有點嚇人......它應該很簡單：
git checkout --detach master # let's get ourselves on top of master, but let's not move it around
git cherry-pick first-commit-of-the-branch-you-want #you probably have more than one _first_ commit in the messy branch, any of those _firsts_ would do, use its commit ID
git cherry-pick second-commit-of-the-branch-you-want # same thing with the second
git cherry-pick third-commit-of-the-branch-you-want
# if this is your branch and it looks good (straight line from master, 3 commits, no merges):
git branch -f feature-branch
git push -f
你從地獄里出來了。現在你可以開始使用我在開始時描述的食譜了。
uj5u.com熱心網友回復：
作為一般規則，重新設定已經推送的分支是一個壞主意。在這種情況下，在你 rebase 之后——在 master 的頂端創建新的提交——你將原始功能分支及其所有提交拉（并合并）到你的 rebase 分支中，然后將整個事情向上推。
結果，合并基礎保持不變，自那時以來的所有提交現在都在“您的分支上”，包括您的提交的兩個副本。
他們在審查時應該沒有問題，因為通常他們會查看差異，而不是單個提交。但是，您已經完全破壞了單行歷史記錄的目的（通常需要 rebase 而非合并的原因），因為您引入了合并。
在這些情況下，如果您已經推送代碼并將 PR 指向新分支，則通常最好創建一個新分支，以避免兩個歷史版本之間的交叉污染。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/512142.html