问题
I just got done with a particularly hairy rebase (someone worked for weeks on a branch without ever rebasing.) It took me about two or three hours because the "human readable" format that I was using is just a bunch of IDs and references.
While I was doing this rebase, two more commits showed up on the branch before I had the chance to git push the result of the rebase.
Is there a best practice for getting those new commits without re-doing the rebase or resorting to a merge? My initial thought was that I could git cherry-pick those new commits and git push -f, but would that be unsavory?
回答1:
You should be able to rebase your commits again.
The only issue is that you will have to remake your conflict resolutions, because you did not activate git rerere.
Well,... you don't have to, with the rerere-train.sh script.
See "Do you even rerere?" by Tristan Roussel:
In this simplest form, the script starts from the commit you specified and go through every parent commit to look for conflicts.
That will allow you to record those past conflict resolutions, and rebase again without having to do them again.
回答2:
cherry-pick for just merging specific commits but if your branch contains many commits that needs to be merged then better to rebase it.
Different people may have different best practices. I follow followings:
git pull --rebaseso that I can ensure my branch is up to date from the remote branch it was created.git push origin :feature_branchthis will delete remove remote feature branch. Though I know I can simply dogit push -force feature_branchbut I want to be confirm that git will not mess up anything :) :) :)- finally
git push origin feature_branch
I will be glad to know your practice or suggest me something better.
来源：https://stackoverflow.com/questions/40822333/what-to-do-when-new-commits-happen-after-a-git-rebase