问题
I recently had to pull a feature out of our 'dev' branch because it's being put on hold until a later date.
To do so, I created a branch whose parent is on 'dev' one commit before the first feature commit (the first feature commit was a squashed merge from another branch.) I then cherry-picked all of the feature commits from dev into the new branch. Finally I made one big revert commit on dev to remove those cherry-picked commits.
Now I want to rebase the new branch on dev to get it up to date. If I run "git rebase dev", the head of the new branch becomes the big revert, so the feature is lost.
With "git rebase --strategy=ours dev" all the commits in the feature branch are skipped with the message "Already applied: 0001...".
How can I rebase the feature branch onto dev such that all the commits on the feature are applied to the head of dev?
Maybe there's a better way to go about this process than what I've described here?
回答1:
You can fix this by checking out your feature branch and doing:
git rebase --onto dev HEAD~<number of commits you care about> --force-rebase
This instructs git to replay the commit range that you specify and to ignore whether or not the commit occurred at a point in time prior to the commits on dev.
Note that this will leave you with a history that looks like:
<did some work> -- <reverted all of that work> -- <re-did that work>
which may not be all that useful to you. Some of the other answers here detail how you can get a cleaner history by rewriting it, depending on your team's tolerance for history rewriting.
回答2:
Assuming that you don't mind rewriting history, a better way to do whole thing would have been an interactive rebase:
- Create a branch foo just before the commit to be removed.
- To avoid losing it, tag or make a branch at the commit to be removed.
- Put yourself on the branch in question (e.g. git checkout your-dev-branch).
- git rebase -i foo
- You'll be put into an editor with "pick" lines for each commit between foo and the current head. Delete the line[s] for the commit[s] that you want to remove. Save, quit
- Resolve any conflicts.
This will
- Rewrite the dev branch with the relevant commits removed.
- Leave the pulled feature on a branch (or tagged, depending on the second step), for later cherry-picking (or otherwise) onto your revised dev branch. I'd always take a clone or put a few judicious tags in there before doing this sort of thing, in case it all goes wrong.
回答3:
Am not an expert, but how about reverting the feature and then creating the branch followed by the cherry pick of the feature sha1s on the new branch.
来源：https://stackoverflow.com/questions/22461088/git-cherry-picked-feature-commits-into-new-branch-reverted-commits-rebase-no