Merge y resolución de conflictos

Objetivo

Resolver conflictos entendiendo la intención de ambas ramas.

Explicación

Un conflicto aparece cuando Git no puede combinar cambios automáticamente. No se resuelve eligiendo “ours” o “theirs” a ciegas: debes construir el contenido final correcto y probarlo. Git y GitHub son parte del trabajo diario de un equipo de datos. No basta con memorizar comandos: debes ser capaz de dejar cambios pequeños, revisables y reproducibles, evitar secretos y explicar qué cambia un Pull Request antes de mezclarlo. Para trabajar Merge y resolución de conflictos de forma profesional, no te quedes con el ejemplo: identifica la entrada, ejecuta el caso base, provoca al menos un caso incorrecto y compara el resultado con un control independiente. En este laboratorio el criterio de salida es concreto: git status queda limpio y README contiene el resultado acordado. La verificación principal será: Busca marcadores <<<<<<>>>>>> antes del commit. Si no puedes explicar por qué pasa esa comprobación, vuelve al paso anterior antes de continuar.

Contexto profesional

Git y GitHub son parte del trabajo diario de un equipo de datos. No basta con memorizar comandos: debes ser capaz de dejar cambios pequeños, revisables y reproducibles, evitar secretos y explicar qué cambia un Pull Request antes de mezclarlo.

Ejemplo real

git switch -c feature/a
# cambia README
git switch main
git switch -c feature/b
# cambia la misma línea

Archivos o datos de entrada

• templates/README-template.md
• templates/.gitignore-data

Práctica guiada

Provoca un conflicto en README y resuélvelo.

Laboratorio paso a paso

• Prepara el entorno y localiza los datos/archivos de entrada: templates/README-template.md, templates/.gitignore-data. Antes de modificar nada, anota el número de filas, columnas u objetos que esperas usar.
• Reproduce el ejemplo real de la lección y guarda la salida. No avances hasta poder explicar qué hace cada bloque relacionado con «Merge y resolución de conflictos».
• Ejecuta la práctica guiada: Provoca un conflicto en README y resuélvelo. Documenta el comando, consulta o acción exacta y el resultado obtenido.
• Resuelve el reto sin mirar la solución: Conserva información válida de ambas ramas y verifica Markdown. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
• Compara tu resultado con el criterio esperado: git status queda limpio y README contiene el resultado acordado. Después ejecuta la comprobación: Busca marcadores <<<<<<>>>>>> antes del commit.
• Provoca deliberadamente un caso problemático relacionado con este error frecuente: Resolver un conflicto sólo para que Git deje de quejarse puede borrar trabajo.. Comprueba que sabes detectarlo y corregirlo.

Reto sin ayuda

Conserva información válida de ambas ramas y verifica Markdown.

Resultado esperado

git status queda limpio y README contiene el resultado acordado.

Cómo verificarlo

Busca marcadores <<<<<<>>>>>> antes del commit.

Checklist de validación

• El resultado cumple: git status queda limpio y README contiene el resultado acordado.
• Has ejecutado esta verificación y puedes explicar el resultado: Busca marcadores <<<<<<>>>>>> antes del commit.
• Has probado al menos un caso límite o dato inválido y el comportamiento es explícito, no silencioso.
• Puedes repetir la práctica desde cero sin copiar la solución y dejar evidencia (consulta, commit, captura o salida de consola).

Errores frecuentes

• Resolver un conflicto sólo para que Git deje de quejarse puede borrar trabajo.

Qué debes recordar

Un repositorio profesional permite entender, reproducir y revisar el trabajo.

Preguntas de entrevista

• ¿Qué debería contener un commit o PR para que sea revisable? Aplícalo concretamente a «Merge y resolución de conflictos».
• ¿Cómo evitarías subir secretos o cambios accidentales al repositorio? Explica qué evidencia enseñarías al revisor.

Siguiente paso

Pasarás a GitHub y Pull Requests.

Recursos de esta lección