¿Cómo se fusiona git después del trabajo de selección de cereza?

Imaginemos que tenemos una masterrama.

Entonces creamos un newbranch

git checkout -b newbranch

y hacer dos nuevos compromisos para newbranch: commit1 y commit2

Luego cambiamos a maestro y hacemos cherry-pick

git checkout master
git cherry-pick hash_of_commit1

Mirando hacia adentro gitk, vemos que commit1 y su versión seleccionada tienen diferentes hashes, por lo que técnicamente son dos commits diferentes.

Finalmente nos fusionamos newbranchen master:

git merge newbranch

y vea que estos dos commits con diferentes hashes se fusionaron sin problemas, aunque implican que los mismos cambios deberían aplicarse dos veces, por lo que uno de ellos debería fallar.

¿Realmente git hace un análisis inteligente del contenido de commit mientras se fusiona y decide que los cambios no deberían aplicarse dos veces o que estos commits se marcan internamente como vinculados?

Respuesta corta

No te preocupes, Git lo manejará.

Respuesta larga

A diferencia de, por ejemplo, SVN ¹ , Git no almacena confirmaciones en formato delta, sino que se basa en instantáneas ^2,3 . Si bien SVN intentaría ingenuamente aplicar cada confirmación combinada como un parche (y falla, por la razón exacta que describió), Git generalmente puede manejar este escenario.

Al fusionarse, Git intentará combinar las instantáneas de ambas confirmaciones HEAD en una nueva instantánea. Si una parte del código o un archivo es idéntica en ambas instantáneas (es decir, porque una confirmación ya fue seleccionada), Git no lo tocará.

Fuentes

¹ Skip-Deltas en Subversion
² Conceptos básicos de Git
³ El modelo de objetos Git

Después de tal fusión, es posible que haya confirmados dos veces en la historia.

Solución para evitar esto, cito del artículo que recomienda que las ramas con confirmaciones duplicadas (seleccionadas con cereza) usen rebase antes de fusionar:

git merge after git cherry-pick: evitando confirmaciones duplicadas

Imagina que tenemos la rama maestra y una rama b:

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

Ahora necesitamos urgentemente los commits b1 y b3 en master, pero no los commits restantes en b. Entonces, lo que hacemos es verificar la rama maestra y los compromisos de selección de cereza 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 fusionáramos la rama b en master:

$ 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 eso, podemos cambiar la base en lugar de fusionar:

$ git rebase master b

Lo que producirí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

EDITAR Correcciones supuestas por el comentario de David Lemon