The git-cherry-pick(1) man page says:
Given one or more existing commits, apply the change each one
introduces, recording a new commit for each. This requires your working
tree to be clean (no modifications from the HEAD commit).
In plain English, this means that git cherry-pick
applies commits from one branch to another, but does not preserve the original history or ancestry from the other branch in the way that a proper merge would do.
Think of it as applying a series of selected patches, rather than a full merge of two branches of history. Obviously, if you tend to make very small, atomic commits then cherry-picking looks exactly like applying a well-written patch. However, since you don't have common ancestors the way you do with merge or rebase, you may have a lot more conflicts to resolve if your commits aren't small and isolated.
Whether or not cherry-picking is a good idea is highly dependent on how you structure your commits. If it doesn't work for you, you can always do things more manually with git format-patch
and git apply
instead.