git - cherry-picked feature commits into new branch, reverted commits, rebase not working as expected

Question

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?

Answer 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.

Answer 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.

Answer 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.