Fusionar seguimiento para la recolección de cerezas de Git?

Por ejemplo, tengo una twig dev y una twig stable .

En caso de que haya seleccionado varios commit de dev a stable .

¿Hay alguna manera de que Git esté al tanto de los commits seleccionados y evite fusionarlos dos veces si luego fusiono, rebase o selecciono un range superpuesto, desde dev a stable ? (para lo cual es una característica básica de seguimiento de fusión en SVN)

En realidad, hay un command llamado git cherry que imprime cada confirmación que no se fusiona entre dos twigs.

Para cada confirmación impresa, el signo "+" significa que puede fusionarlo, el signo "-" significa que ya seleccionó esa confirmación.

La salida está lejos de ser bonita.

Para aquellos que vinieron de SVN y están acostumbrados a svnmerge.py , hice un script de bash "svnmerge avail-equivalente" para git, al que llamé gitavail:

 #!/bin/bash # get current branch CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD) # get tracked branch (1st argument), if no arg or arguments are only options, assume master if test -z $1 || grep -q '^-' <<< $1; then TRACKED_BRANCH=master else TRACKED_BRANCH=$1; shift fi # Log commits available for merge from tracked branch LOG_OPTIONS=$* for i in $(git cherry $CURRENT_BRANCH $TRACKED_BRANCH | egrep '^\+' | awk '{print $2}'); do git --no-pager log -n1 $i ${LOG_OPTIONS}; echo; done 

Suponiendo que está en una sucursal y desea enumerar qué es elegible para fusionarse de la sucursal principal, simplemente ejecute:

 gitavail --name-status 

Y tendrá una salida muy similar a "svnmerge avail -l".

Supongo que las confirmaciones de selección no deben modificarse manualmente (¿qué pasa con los conflictos?), Si la identificación del parche cambia, git cherry no se dará count de que la confirmación ya ha sido seleccionada.

También es notable que la bandera -x para cherry-pick agrega el SHA de la confirmación original al final del post de confirmación.

Me gusta agregar el SHA abreviado al final del resumen de compromiso, también, para facilitar la asociación de la confirmación seleccionada con el original al mirar el logging. Indicar quién hizo la selección de cereza también puede ser útil, con la bandera de firma de -s .

Ejemplo:

> git cherry-pick -sex 27d4985

 #333: fixes all the things (27d4985) - how it fixes all the things (cherry picked from commit 27d49855238364d0184ad344884a366b5b16e) Signed-off-by: Chuck Norris <chuck@example.com> 

git cherry-pick es un caso divertido de git rebase lugar de git merge , por lo que en realidad reescribe la confirmación que git rebase para que aplique los mismos cambios en la parte superior de la twig en la que seleccionaste. Dado que las identificaciones de commit de git se basan en el contenido de la confirmación, la nueva confirmación tiene una identificación diferente y, por lo tanto, se considera una confirmación completamente diferente por parte de git.

git merge , por otro lado, crea un commit de fusión; este es el medio por el cual git implementa el seguimiento de fusión. Una fusión de compromiso marca un punto en el que convergen dos (o más) historias divergentes. Es aceptable llamar a git merge [commit-id] lugar de a git cherry-pick [commit-id] para crear explícitamente un commit de fusión, pero esto trae no solo los efectos de la única confirmación seleccionada, sino también todo el set de cambios en la historia divergente de esa twig.

Con todo lo dicho, "doble fusión" no suele ser un problema en git. Si intenta fusionarse con un historial que contiene un set de cambios que ya está presente, se convertirá en un no-operativo cuando los historiales estén pegados; A git realmente le importa solo el estado del tree en cada compromiso, no los cambios que lo llevaron a ese estado.