Don't cherry-pick. Branch out and merge.
Healthy bookmark: Need to bring some changes from branch A to branch B, e.g. a hotfix from main onto development, a set of commits from one line onto another, whatever. Don’t cherry-pick it into the destination.
Cherry-picks copy the cahnges and throw away the relationship. Git no longer treats those two commits as the same change. Later, when the branches actually merge, you can get conflicts from hell, or worse, the merge silently drops some of the incoming changes.
Do this instead:
- Branch C off a common ancestor of A and B.
- Cherry-pick the changes onto C. This is the one cherry-pick that is allowed.
- Merge C into A and into B. Even if one of those merges has no diff. Do it anyway.
The empty merge is the point. You are not applying the patch twice. You are recording that both branches already contain this change, via a shared parent. Next time A and B merge, that parent is the merge base, and git treats the patch as already accounted for.
For a detailed explanation of how the potential issues and how this solves them, see Raymond Chen blog series of Stop cherry-picking, start merging.