I was working on my feature branch and after review, merged it into development to be deployed. Later, a coworker decided to do a release and merged his and mine into master. While deploying he realized his code was buggy and reverted master.
In our fork-and-pull flow, that means that now development and master are both reverted.
When I came in this morning, I rebased from development per usual, to learn afterward there had been a revert.
Now I'm trying to cherry-pick my work from the original feature branch only to realize it gives me "empty commit messages" because of the revert.
- is this because revert is a mirror image of my previous commits?
- is there a way to revert the revert? (makes my head hurt)
- is there anyway to get my commits to show up in the diff now that my I have rebased
Any help is greatly appreciated.
Cherry-pick and rebase checks the patch id of the commit (basically a hash of the change) and already sees that the change exists on the branch, so it doesn't pick it. Rebasing can sometimes work because changes in the files may have caused the actual diff to change a bit--resulting in a different patch id--but that doesn't appear to be the case for you.
You can "revert the revert", though that will re-introduce the broken bits your co-worker introduced. Then you need to revert the buggy commits your co-worker made. It's a lot of reverting, and quite a bit to keep straight, so take it slow and have someone sit with you just to make sure you don't miss anything.
Another choice might be to replay your commits by doing git show COMMIT_ID | git apply. This re-applies the diff to your working tree. As long as your tree is clean, you can use git commit -C COMMIT_ID to re-use the message from the original commit. You can probably use git format-patch and git am to avoid the extra steps.
来源：https://stackoverflow.com/questions/23681754/how-to-cherry-pick-commits-after-theyve-been-reverted