Does picking a range of commits with cherry-pick or rebase –onto end up with the same result?

I sometimes want to pick a range of commits from a different repository. I know two ways to do that.


git checkout myBranch
git cherry-pick begin..end


  1. git rebase --onto myBranch begin end

I find the first version easier to remember. However, I read a lot about how cherry-picking is evil compared to merging because it kinda breaks the history. But what I haven’t figured out yet is if there is a difference between cherry-picking a range of commits or rebasing them with --onto

I tend to think that there shouldn’t be a difference. Am I mistaken?

  • Can't find `HEAD` in git rebase conflict?
  • Where does git rebase make changes
  • Should I rebase master onto a branch that's been pushed?
  • git rebase: “error: cannot stat 'file': Permission denied”
  • Git - Moving Pushed Commits to a Different Branch
  • git - remove commits from merged branch
  • How to perform a rebase onto a specific commit?
  • How to avoid git rebase killing merge commits?
  • 3 Solutions collect form web for “Does picking a range of commits with cherry-pick or rebase –onto end up with the same result?”

    These two commands are equivalent, you’re just doing the work that a normal rebase would do to figure out the unmerged commits to replay onto the target branch.

    Rebasing and cherry-picking are just as ‘bad’ for merges. They both result in forgetting the IDs of the original commits for the changes you pick up; as a result, later merges may attempt to apply the same changes more than once.

    Actually, cherry-picking is less evil in this respect than rebasing. Cherry picking will create duplicates of commits, while rebasing will actually move them (thus rewriting history).

    Both are more evil then merging, which in my honest opinion is usually the worst choice.

    Git Baby is a git and github fan, let's start git clone.