Pour retrouver l'ensemble des branches où se trouvent un commit selon le message de commit de celui-ci (par exemple si vous travaillez avec des gens qui restent dans leurs habitudes archaïques d'utiliser du cherry-pick comme ils le faisaient avec subversion(svn)), vous pouvez utiliser ceci:
$ git log --all --pretty=oneline --source --grep='message de commit'
821da26c7a3123674cfdc30e6b1ed22d629d003a refs/heads/develop anno #124 - message de commit
9cdb2334a43b7f68e10e1544463998727210ed91 refs/heads/master anno #124 - message de commit
Il ne « reste » plus qu'à chercher les différences entre ces deux commits (puisque l'utilisation de cherry-pick permet d'ajouter des différences à un commit cherry-picked):
$ git diff 821da26c7a3123674cfdc30e6b1ed22d629d003a 9cdb2334a43b7f68e10e1544463998727210ed91
Il est temps que les gens arrêtent d'utiliser les cherry-pick qui sont faits pour récupérer en ultra urgence un commit déjà effectué pour l'inclure en urgence dans une branche. Ce n'est pas fait pour synchroniser deux branches entre elles car on perd toute traçabilité et on introduit le risque majeur d'oublier des commits.
Le cherry-pick n'est pas une fonction de synchronisation de branches.
Il est même possible de ne jamais l'utiliser en créant une branche spécifique pour un commit de type hotfix, branche qui sera alors mergée sur les différentes branches où le commit doit apparaître.
Quelques informations là dessus pour approfondir:
Why cherry-picking should not be part of a normal git workflow