theirs - git pull conflict

¿Por qué después de la fusión GIT dice "Ya está actualizado", pero las diferencias entre las sucursales siguen existiendo?

Question

Originalmente estaba trabajando en la rama ''newfeature'' y me llamaron para corregir un error en la rama en vivo con urgencia. Creé una rama para el llamado ''mantenimiento general'', hice el trabajo y luego cambié a desarrollo y lo fusioné. Ahora quiero volver a la rama ''nueva característica'' y fusionarme en los cambios que fusioné anteriormente.

Cuando cambié a ''newfeature'' y me fusioné en ''desarrollar'', hubo conflictos en 3 archivos.

Me metí en un enredo resolviendo los conflictos y finalmente decidí usar el comando "Revertir" en el menú ''Equipo'' de Aptana Studio 3 (que es mi IDE). Esperaba que esto me hiciera retroceder antes de la fusión, lo que parece haber hecho.

De todos modos, cuando me fusiono en ''desarrollar'' otra vez, dice: Already-up-to-date , pero al comparar archivos entre las dos ramas, son muy diferentes y los cambios que agregué en la otra rama no se están fusionando.

¿Cómo voy a combinar las dos ramas ahora, por favor?

Answer 1

Revertir Fusiones vs Restablecer Fusiones

Mi conjetura es que usted Already-up-to-date .

El problema es que git revert no deshace la fusión, solo deshace los cambios que la fusión trajo consigo. Cuando crea una confirmación de fusión, combina los historiales de confirmación de esas dos ramas.

Fusionando

     develop
        |
A---B---C
 /       /
  E---F---M
          |
      newfeature

En el caso anterior, el develop se fusiona en newfeature , creando el M commit. Si ejecutara git log newfeature vería todas las confirmaciones de ambas ramas, sin embargo, desde la perspectiva de la newfeature , todos los cambios fueron realizados por la confirmación M

Volviendo

El comando git revert no elimina ninguna confirmación, sino que crea una nueva confirmación que deshace los cambios que la confirmación contenía. Por ejemplo, si tuviera un commit que contenga esta diferencia ...

-This is the old sentence.
+This is ne new sentence.

Luego, revertido esto, el comando revert crearía una nueva confirmación que simplemente realizó la diferencia opuesta, simplemente voltea las señales.

-This is ne new sentence.
+This is the old sentence.

Esto es realmente útil para deshacer el daño causado por las confirmaciones que otros desarrolladores ya tienen. Hace avanzar la historia en lugar de cambiar la historia.

Revertir Fusiones

Sin embargo, en el contexto de una fusión no rápida, puede tener un efecto no deseado.

     develop
        |
A---B---C
 /       /
  E---F---M---W
              |
         newfeature

Suponiendo que W es una confirmación de reversión, puede ver cómo la ejecución de git log newfeature incluirá todas las confirmaciones de la rama desarrollada. Como resultado, las combinaciones adicionales del develop no funcionarán, porque no ve nada que falte en su sucursal.

Usando git reset en lugar de revertir.

En el futuro, es posible que desee considerar el uso de git reset --hard <ref> (donde <ref> es el hash de confirmación de la combinación) para deshacer una fusión si esa combinación no se ha compartido con otros desarrolladores. En el ejemplo anterior, después de haber creado la confirmación de fusión M , ejecutar el comando git reset --hard F resultaría en lo siguiente.

     develop
        |
A---B---C
 /       /
  E---F---M
      |
  newfeature

Como puede ver, esta técnica no borra el compromiso como algunas personas tienden a pensar, simplemente mueve su rama hacia el compromiso que seleccionó. Ahora, si ejecuta git log newfeature , solo obtendría el commit F , E y A Ahora, la fusión ha desaparecido de la historia de sus sucursales, por lo que los intentos posteriores para volver a combinar en el develop no causarán problemas.

Este método no está exento de complicaciones. Tenga en cuenta que ahora está modificando el historial, por lo que si la rama de la newfeature fue empujada a una rama remota después de la fusión, git pensará que simplemente está desactualizado y le dirá que necesita ejecutar git pull . Si solo estás trabajando en esa rama remota, siéntete libre de force-push - git push -f <remote> <branch> . Esto tendrá el mismo efecto que el reinicio pero en la rama remota.

Si esta rama está siendo utilizada por múltiples desarrolladores, quienes ya habrían retirado ya, entonces esta es una mala idea. Esta es la razón por la que git revert es útil, ya que deshace los cambios sin cambiar el historial real.

El uso de restablecer en el historial es realmente solo una opción para las confirmaciones que no se han compartido.

La solución - revertir la reversión.

Si el compromiso de fusión ya se ha compartido, entonces el mejor enfoque es probablemente usar git revert en esa fusión. Sin embargo, como dijimos anteriormente, no puede simplemente volver a combinar la rama y esperar que todos los cambios de esa rama vuelvan a aparecer. La respuesta es revertir la confirmación de revertir.

Digamos que hiciste un trabajo en la rama de develop después de haber reverenciado la fusión en las newfeature . Tu historia se vería algo así.

         develop
            |
A---B---C---D
 /       /
  E---F---M---W
              |
         newfeature

Si fusionas el develop en newfeature ahora, solo obtendrás D porque es la única confirmación que aún no forma parte de la historia de la rama newfeature . Lo que también debe hacer es revertir que W commit - git revert W debería hacer el truco seguido de git merge develop .

                 develop
                    |
A---B---C-----------D
 /       /           /
  E---F---M---W---M---G
                      |
                 newfeature

Esto restaura todos los cambios realizados por la confirmación de combinación original, que en realidad fueron realizados por C y B pero se revirtieron en W , luego se introduce en D través de una nueva confirmación de fusión G Recomendaría revertir la reversión antes de fusionar en los cambios recientes develop , sospecho que hacerlo en ese orden tendrá una menor probabilidad de desencadenar conflictos.

TL; DR

Revertir crea un ''revertir confirmación''. Al deshacer una reversión, debe ejecutar el comando revertir en la confirmación de reversión que se creó al revertir la primera vez. Debería ser lo suficientemente fácil de encontrar, git tiende a comentar automáticamente los revertimientos para que comiencen con la palabra "Revertido".

git revert <commit>