Deja de copiar, es hora de fusionar. Parte 1. Fusionar conflicto

Si bien la operación git cherry-pick es común en Git, generalmente no es la mejor solución. A veces, este es el menor de dos males, pero todavía no he visto una situación en la que sea apropiado.







Esta es la primera parte de una serie que comienza explicando por qué copiar es malo, continúa con por qué es terrible y luego describe cómo obtener el mismo resultado usando la combinación. Te mostraré cómo aplicar esta técnica cuando necesites hacer una fusión retroactiva y cuando quieras arreglar la copia para fusionar antes de que suceda algo malo.







Dos ramas están involucradas en la copia: el donante (de donde proviene el compromiso) y el receptor (donde se copia). Llamémoslos maestro y función respectivamente. Para simplificar, supongamos que la confirmación que está copiando contiene el cambio en solo una línea de un solo archivo. En este diagrama, cada confirmación está marcada con el contenido de esa línea y la flecha discontinua indica la copia (operación git cherry-pick



) en sí.







Primer diagrama







, , .







- "apple". , F1 feature, M1 master. , "apple". F2 feature, "berry", F2 master M2.







.







, :







El segundo







3 master F3 feature. , "berry".







feature master. , , "berry".







Después de la fusión 1







, , , .







. F2 3 master F3 feature, F3 "cherry". , feature, , "cherry". , :







¡Una bomba!







feature master . (three-way merge) "apple", feature "cherry", — "berry".







<<<<<<<<<< HEAD (master)
berry
||||||||| merged common ancestors
apple
=========
cherry
>>>>>>>>>> feature
      
      





, , . , .







, , , feature.







( , .). ?







Pesadilla de tres miembros







, "apple". victim A V1, . V1 feature : F1 , "apple". master 1, .







. feature "berry" F2, master M2. "cherry" feature F3. master 3, , master "berry".







victim "-" feature master. V2 V3, "apple".







- , feature victim, V4 , "cherry" feature.







"" victim, master. ! : "" F2 M2. , , , () , .







En resumen, el problema: cuando git cherry-pick



aparecen dos copias de una confirmación en el árbol. Si al menos una de sus líneas cambia antes de fusionar sus copias, surgirá una colisión no forzada. Además, esto puede suceder en una semana o en un año. Esto significa que el que lo resolverá puede que simplemente no tenga los recursos para tomar la decisión correcta (no copió, el equipo cambió por completo, etc.).







Sin embargo, ¡todo esto de Santa Bárbara podría empeorar si el conflicto no ocurre!







¿Por qué? Siga leyendo en la siguiente parte.








All Articles