Suena como es posible que desee hacer esas confirmaciones en una rama distinta de maestro, y luego fusionar esa rama para el maestro y su segunda rama:
git checkout working-branch
<do some work>
git commit
git checkout master
git merge working-branch
git checkout second-branch
git merge working-branch
Esto es mucho, mucho mejor que la Cereza- picking porque no implica la duplicación de commits en el historial, se deshace de cualquier problema relacionado con el hecho de seleccionar dos veces (lo cual debe evitar manualmente) ... y es la forma en que git está diseñado para funcionar. No sé cuál es su segunda rama, pero lo que estoy describiendo es esencialmente el flujo de trabajo común de fusionar periódicamente las ramas de mantenimiento y tema de nuevo en el maestro, así como en cualquier otra rama apropiada de liberación modificada o mantenimiento.
Recomiendo encarecidamente que adopte un flujo de trabajo en el que esto se realice mediante la fusión tal como lo describí anteriormente, pero para responder la pregunta que hizo, si debe trabajar definitivamente en master y cherry-pick, puede escribir un pequeña secuencia de comandos, algo así como:
#!/bin/bash
# take two arguments:
# 1. other branch to put commits on
# 2. number of commits to cherry-pick from master
if ! git checkout $1; then
exit
fi
git rev-list --reverse -n $2 master |
while read commit; do
if ! git cherry-pick $commit; then
exit
fi
done
Obviamente hay formas de hacer que la secuencia de comandos sea más robusta, por ejemplo agregando la capacidad de reanudar después de selecciones de cereza cuyos parches no se aplican correctamente, pero es un comienzo.
Puede perder el tiempo con la forma en que usa git-rev-list para seleccionar las confirmaciones, por supuesto. Incluso podría pasar todo, excepto el primer argumento junto a git-rev-list, para que pueda hacer cherries-pick <branch> -n 5 master
o cherries-pick <branch> release_tag..master
o lo que quiera. ¡Eche un vistazo a su man page!
También puede utilizar git-rebase
como se ha sugerido en otro lugar, pero debido a que en realidad no desea mover maestro, que terminará haciendo algo como esto:
git branch master-copy master
git rebase --onto <branch> master~5 master
git checkout <branch>
git merge master-copy
git branch -d master-copy
¡Muy impresionante, gracias! –