Diferencias

Muestra las diferencias entre dos versiones de la página.

--- informatica:programacion:cursos:control_version_git_avanzado:conflictos [2023/05/29 11:09] – tempwin
+++ informatica:programacion:cursos:control_version_git_avanzado:conflictos [2023/06/01 19:09] (actual) – tempwin
@@ Línea 4: / Línea 4: @@
 ===== Introducción =====
+Uno de los grandes quebraderos de cabeza de los que se inician en Git son los conflictos.
 ===== Qué significan y cómo resolverlos =====
+Un conflicto no es un error.
+Un conflicto aparece cuando hay dos versiones de código y Git no puede decidir cuál es la definitiva.
+Esto pasa por ejemplo cuando mezclamos dos ramas y en una hay un archivo que contiene un texto en una línea y en la otra existe el mismo archivo, pero con otro texto en esa línea.
+A veces los conflictos también son diferencias en el formato del archivo (tabulaciones, codificación de caracteres, saltos de línea...).
+También pueden aparecer conflictos en cualquier operación que implique fusión de código:**merge** (fusiona dos ramas), **rebase** (también fusiona ramas), **cherry-pick** (aplica un commit de otra rama en la rama en la que estamos), **pull** (trae código del repositorio remoto al local).
+**Regla de oro**: Siempre que aparezcan conflictos, primero lanzar ''git status''. Esto nos dará más información sobre lo que podemos hacer.
+Git espera a que resolvamos los conflictos y le demos la orden de cerrar la operación.
+Los conflictos se delimitan por marcas en los archivos:
+<code>
+<<<<<<< HEAD
+    // Código del commit o rama
+    // a donde apunta el HEAD
+=======
+    // Código del commit o rama
+    // que estoy intentando fusionar con HEAD
+>>>>>>> develop
+</code>
+En la parte de arriba está el código actual y en la parte de abajo el código que viene de otro repositorio, commit o rama.
+Cuando Git nos enseña conflictos, lo primero que hay que hacer es buscar el separador (''%%=======%%'') para ver cuántos bloques de conflicto hay.
+Si queremos resolverlos a mano, editaremos el texto, borraremos las marcas y dejamos el código definitivo.
+Una vez resueltos los conflictos, se lo comunicamos a git:
+<code>
+git add <RUTA>
+</code>
+Para terminar la fusión en un ''merge'' o en un ''pull'':
+<code>
+git commit
+</code>
+Para terminar la fusión en un ''rebase'':
+<code>
+git rebase --continue
+</code>
+Para terminar la fusión en un ''cherry-pick'':
+<code>
+git cherry-pick --continue
+</code>
+<WRAP center round tip 60%>
+Recordemos usar ''git status'' para obtener consejos sobre cómo terminar las operaciones de conflictos sin tener que sabérnoslo de memoria.
+</WRAP>
 ===== Herramientas para resolver conflictos =====
+Si queremos usar una interfaz gráfica específica para resolver conflictos:
+<code>
+git mergetool
+</code>
+<WRAP center round info 60%>
+''mergetool'' solo funcionará cuando haya conflictos
+</WRAP>
+''git mergetool'' lo que hace es llamar a la herramienta gráfica que le hayamos indicado a través de la variable ''merge.tool''. Por ejemplo, para usar el programa [[https://kdiff3.sourceforge.net/|KDiff3]]:
+<code>
+git config --global merge.tool kdiff3
+git config --global mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
+</code>
+Al usar una herramienta gráfica, git crea una copia del fichero origen del conflicto con las marcas de conflicto por si queremos revisar (añade la extensión ''.orig'').
 ===== Conclusión =====
+Un conflicto no es un error. Es parte del flujo de trabajo habitual con git siempre que estemos fusionando código.
+Git hay cosas que no puede resolver él solo y requiere de intervención humana para decidir.
+Cuando hay conflicto, ''git status''. Antes de cerrar el conflicto, ''git status''. Es muy recomendable el uso de este comando por la ayuda que nos ofrece.
 ===== Recursos =====