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 cherry-pick -x: link in details instead of in summary
  • Check if all commits to one GIT branch have been cherry picked to another
  • Git revert/cherry-pick to a commit beyond a merge
  • Git: how to push changes made to only certain files?
  • What are the differences between git cherry-pick and git show | patch -p1?
  • Can't cherry pick (error)
  • 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?

  • Problems SourceTree listing files in local repository as deleted
  • git post-receive hook that grabs commit messages and posts back to URL
  • Random 'concerns' folders and '.keep' files
  • Gitignore all folders beginning with a period
  • How to always show full-history in Git?
  • See what would be merged in one git command?
  • 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.