在 git rebase 之后发生新提交时该怎么办？答案

【问题标题】：What to do when new commits happen after a git rebase?在 git rebase 之后发生新提交时该怎么办？
【发布时间】：2017-04-10 21:05:06
【问题描述】：

我刚刚完成了一个特别复杂的变基（有人在一个分支上工作了数周而从未变基。）我花了大约两三个小时，因为我使用的“人类可读”格式只是一堆 ID和参考。

当我做这个变基时，在我有机会 git push 变基的结果之前，分支上又出现了两个提交。

在不重新进行变基或诉诸合并的情况下获得这些新提交是否有最佳实践？我最初的想法是我可以 git cherry-pick 那些新的提交和 git push -f，但这会不好吃吗？

【问题讨论】：

rebase 只是一系列自动挑选的，所以你确实可以挑选那些额外的提交。一般来说，像这样重新设置共享分支是不礼貌的，出于同样的原因，将未经通知的推送到将像这样重新设置的分支是不礼貌的。您和其他人需要在此处就协议达成一致：这是否会被重新设置并且每个人都必须为此做好准备，或者是永久提交并且没有人必须重新设置，或者是否有一些混合，人们应该进行更多的交流？ :-)
是的，对方知道rebase要来了。（准备合并。）他只是没有意识到自己在分支上，一直在推一堆无关的工作。

【解决方案1】：

您应该能够再次变基您的提交。

唯一的问题是您将不得不重新制定冲突解决方案，因为您没有激活git rerere。

在这种最简单的形式中，脚本从您指定的提交开始，并遍历每个父提交以查找冲突。

这将允许您记录那些过去的冲突解决方案，并再次变基而无需再次执行它们。

【讨论】：

【解决方案2】：

cherry-pick 仅用于合并特定的提交，但如果您的分支包含许多需要合并的提交，那么最好使用rebase 它。

不同的人可能有不同的最佳实践。我遵循以下几点：

git pull --rebase 这样我就可以确保我的分支从它创建的远程分支是最新的。
git push origin :feature_branch 这将删除删除远程功能分支。虽然我知道我可以简单地做git push -force feature_branch，但我想确认 git 不会搞砸任何事情:) :) :)
终于git push origin feature_branch

我很高兴知道您的做法或建议我更好的方法。

【讨论】：