Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

git

git-rebase

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?

like image 651
Matt Avatar asked Mar 17 '14 17:03

Matt


People also ask

Can I cherry pick reverted commit?

The git revert commit command is substantially similar to the command git cherry-pick commit with one important difference: it applies the inverse of the given commit . Thus, this command is used to introduce a new commit that reverses the effects of a given commit.

Can you cherry pick in rebase?

Once you have git cherry-pick down, you can start off by thinking of git rebase as being a faster way to cherry-pick all of the commits in a given branch at once, rather than having to type out their IDs separately.

Can I cherry pick commit from another branch?

You can cherry-pick a commit on one branch to create a copy of the commit with the same changes on another branch. If you commit changes to the wrong branch or want to make the same changes to another branch, you can cherry-pick the commit to apply the changes to another branch.


2 Answers

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.

like image 108
joshtkling Avatar answered Oct 13 '22 06:10

joshtkling


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.
like image 40
user3392484 Avatar answered Oct 13 '22 05:10

user3392484