Replay the last N git commits on a different branch

Question

I accidentally made 10 commits on branch "testing" when I intended to commit them on branch "master". The other commits on the "testing" branch are garbage, so I don't want to merge it with "master". Instead, I just want to replay the last 10 commits on master.

Solution 1

1. git checkout master
2. git whatchanged testing
3. git cherry-pick _________

?

Solution 2

Rebase should do it.

git rebase -p --onto master testing~10 testing

This will copy the last ten commits on testing to master and make that the new testing (the old testing will be an orphan). Then you can merge master to testing as a fast-forward.

git checkout master
git merge testing

Solution 3

As said in comments, the rebase-inspired answer is leaving the 'garbage' commits orphaned.

Just use simple tools:

git checkout master
git merge testing
git checkout testing
git reset --hard HEAD~10   # Go back 10 commits (*1)
git checkout master

(*1) You will only be "losing" commits from the testing branch, since you'll have those commits in master thanks to the merge.

Comments

[Pat Notz]

Just an fyi - cherry-pick will only do one commit at a time, so you'll have to cherry-picket testing~9 then testing~8 then ... testing. That's why I prefer the rebase approach that Talljoe suggested... of course the result is the same. In fact, if you do the rebase interactively, git will actually use cherry-pick under the hood.

[CB Bailey]

Perhaps worth noting that this leaves testing at the same point as master, leaving the 'garbage' commits orphaned. This may or may not be a good thing. Another possibility would be git checkout master; git reset --hard testing; git rebase --onto HEAD@{1} HEAD~10

[Max Nanasy]

@PatNotz git cherry-pick currently can currently do multiple commits at a time (e.g. git cherry-pick testing~10..testing).

[Tim]

You should never use cherry-pick. Read this article for further information.

[user2190601]

@CharlesBailey What git flog are you intending to hit there?

[prasanthv]

@Tim never is quite a strong word to just throw around.

[Tim]

@prasanthv You're right, I mean: never use cherry-pick as a basis of your workflow. Git's cherry-pick is a very useful feature in other circumstances, but should not be used to move commits from one branch to another, there are better tools for that :)

[mpavey]

Doesn't this approach end up merging the garbage commits into master as well as the 10 the OP wants to merge in?

[Tim]

... and now I understand what the OP asked for about these garbage commits. You are right, these are merged in master, forget my suggestion. The question is then does the OP want these garbage commits deleted but the resulting code kept, or totally forget this work? I think that the latter requires cherry-picking while the other needs a rebase.

[LexH]

Is it safe to say that rebase has the advantage of the changes only being in one place, but cherry-pick works better if the changes were already pushed to another repo (e.g., origin)?