pick multiple meaning how from example commits cherry bad another git version-control merge cherry-pick

multiple - Git cherry pick e datamodel integridad



git cherry-pick bad revision (2)

Dado que dos ramas han divergido y un compromiso específico de una rama (y no todo) necesita ser introducido en la otra, git cherry pick logra exactamente eso.

Después de algún tiempo, existe la necesidad de fusionar completamente las dos ramas. ¿Cómo sabrá Git que ya tiene el compromiso que fue elegido en el pasado para que no lo vuelva a introducir?

El artículo " http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/ " mencionado en la respuesta de tonio dice:

Imagina que tenemos la rama maestra y una rama b:

o---X <-- master / b1---b2---b3---b4 <-- b

Ahora necesitamos urgentemente las confirmaciones b1 y b3 en master, pero no las confirmaciones restantes en b. Entonces, lo que hacemos es verificar la rama maestra y cherry-pick confirma b1 y b3:

$ git checkout master $ git cherry-pick “b1’s SHA” $ git cherry-pick “b3’s SHA”

El resultado sería:

o---X---b1''---b3'' <-- master / b1---b2---b3---b4 <-- b

Digamos que hacemos otro commit en master y obtenemos:

o---X---b1''---b3''---Y <-- master / b1---b2---b3---b4 <-- b

Si ahora uniríamos la rama b en el maestro:

$ git merge b

Obtendríamos lo siguiente:

o---X---b1''---b3''---Y--- M <-- master / / b1----b2----b3----b4 <-- b

Eso significa que los cambios introducidos por b1 y b3 aparecerían dos veces en la historia. Para evitar que podamos rebase en lugar de fusionar:

$ git rebase master b

Que daría lugar a:

o---X---b1''---b3''---Y <-- master / b2---b4 <-- b

Finalmente:

$ git checkout master $ git merge b

Nos da:

o---X---b1''---b3''---Y---b2---b4 <-- master, b

(después de este hilo )

El OP añade en el comentario:

Pero aún parece que no entiendo bien cómo funciona la rebase ... Quiero decir, incluso después de la rebasación, ¿no deberían aparecer las confirmaciones de cereza?

No. La página del manual de git commit menciona explícitamente:

Si la rama en sentido ascendente ya contiene un cambio que ha realizado (por ejemplo, porque envió un parche que se aplicó en sentido ascendente), se omitirá ese compromiso .
Por ejemplo, ejecutar git rebase master en el siguiente historial (en el que A ''y A introducen el mismo conjunto de cambios, pero tienen diferente información de envío):

A---B---C topic / D---E---A''---F master

resultará en:

B''---C'' topic / D---E---A''---F master

Puede detectar si ya hay una confirmación en el master con git cherry master (si está en la rama topic ).