我刚刚完成了一个特别多毛的rebase（有人在分支上工作了几周，但没有重新绑定）。我花了大约两三个小时，因为我使用的“人类可读”格式只是一堆ID和引用。在git rebase之后发生新提交时该怎么办？
当我做这个rebase时，在我有机会推动rebase的结果之前，在分支上出现了两个提交。
有没有一种最佳做法来获得这些新的提交而不重新进行rebase或采取合并？我最初的想法是，我可以挑选那些新的提交和git push -f，但这会不会令人讨厌？
你应该可以重新绑定你的提交。
唯一的问题是，您将不得不重新制定冲突解决方案，因为您没有激活git rerere。
那么，你不必，与rerere-train.sh script。
见“Do you even rerere?”的Tristan Roussel：
在这种最简单的形式，剧本从提交指定开始，经过每个家长都致力于寻找冲突。
这将允许您记录那些过去的冲突解决方案，并再次重新绑定，而无需再次执行。
cherry-pick只是合并特定的提交，但如果你的分支包含很多提交需要合并，那么更好rebase它。
不同的人可能有不同的最佳实践。我遵循以下内容：
git pull --rebase这样我就可以确保我的分支是从它创建的远程分支获得最新的。git push origin :feature_branch这将删除删除远程功能分支。虽然我知道我可以简单地做git push -force feature_branch但我想确认git会不会搞砸任何事:) :) :)git push origin feature_branch我会很高兴知道你的做法或建议我的东西更好。
我不知道你是否明白发生了什么事。我做了rebase。但是后来有人偶然地向分支承诺。我问是否可以挑选那些或者是否有更聪明的方法。 （听起来像樱桃采摘是OK。） –
我的意思是樱桃采摘是好的，但对于明确的历史，我的意见总是更好地使用rebase。虽然练习你可以关注，但如果你看到git工作流程，你会发现专门用于修补程序的cherry-pick，但是有明确的历史记录rebase是最好的。如果你再次担心你必须解决冲突，那么VonC答案就是解决方案。 –
rebase只是一个自动化的樱桃挑选系列，所以你确实可以挑选那些额外的提交。总的来说，像这样重新分享共享分支是不礼貌的，因为同样的原因，将未公布的分支推迟到将要像这样重新分配的分支是无礼的。你和其他人需要在这里同意这个协议：这是否会被重新发布，每个人都必须为此做好准备，或者是永久的，没有人必须变身，或者有一些混合，人们应该更多地沟通？ :-) – torek
是的，对方知道rebase即将到来。 （准备合并。）他只是没有意识到他在分支上，并不断推进一堆无关的工作。 –