假设我有一个带有分支主控的存储库。我检查了一个分支功能分支并开始研究它。我提出了一个 PR，并随着时间的推移在 PR 中推送了 3 次提交。假设 master 分支在此期间向前推进了 10 次提交，我必须将 PR 重新设置为 master 分支。我遵循以下命令：
git checkout feature-branch
git rebase master
git pull
git push
这些步骤确实推进了我的 PR，但现在我的 PR 包含 3 + 10 = 13 次提交，这使得审核变得困难。有什么解决办法吗？
好吧....正如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 Interactive，这很好，但可能是一个有点吓人...用cherry-pick应该很简单：
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
你就脱离了地狱。现在您可以开始使用我在开头描述的食谱。
提交），您将原始功能分支及其所有提交拉取（并合并）到您的变基分支中，然后将整个分支向上推。 合并基础保持不变，自该点以来的所有提交现在都在“您的分支上”，包括您提交的两个副本。
他们在审查时应该没有问题，因为通常他们会查看差异，而不是单个提交。然而，您已经完全违背了单行历史记录的目的（需要重新设置基准而不是合并的通常原因），因为您引入了合并。
在这些情况下，如果您已经推送了代码并将 PR 指向新分支，通常最好的做法是创建一个新分支，以避免两个版本的历史记录之间的交叉污染。