pull-changes-resolve-conflicts

Acerca de pull-changes-resolve-conflicts

Un flujo de trabajo guiado para integrar una rama en otra (generalmente pulling o fusionando main con una rama de características) en proyectos con múltiples colaboradores, evitando descartar silenciosamente el trabajo realizado intencionadamente. Se aplica a cualquier flujo de trabajo en equipo basado en Git, siendo las aplicaciones Flows/React un caso común donde los conflictos suelen concentrarse en las estructuras principales de la aplicación, la navegación superior, los módulos de rutas y las carpetas compartidas lib/ o hooks/. El principio central es que la resolución de conflictos nunca debe asumir automáticamente que “main gana” o “el nuestro gana” antes de realizar un análisis, y que los compromisos deben quedar visibles para el usuario antes de editar cualquier marcador de conflicto.

El flujo de trabajo se desarrolla en etapas: primero se obtiene y se integra el contenido (preferiblemente con git fetch seguido de git merge origin/main, a menos que se haya solicitado rebase); luego se informa explícitamente sobre cada archivo no fusionado junto con una breve explicación de qué elementos difieren; a continuación, se realiza un análisis mediante el historial de conversaciones, señales del repositorio (como un PRD.md o commits recientes) y los propios fragmentos de conflicto, utilizando git show :2:path (el nuestro) frente a git show :3:path (el de ellos). Los conflictos se clasifican como ortogonales (seguros para combinar), superpuestos (es necesario elegir o fusionar manualmente) o con riesgo de corrupción (bloques duplicados derivados de fusiones incorrectas). Los resultados se presentan como recomendaciones ordenadas por prioridad y preguntas específicas, desde P0 (cambios estructurales o en el producto, como rutas eliminadas, características descartadas, cambios en datos o contratos de API) hasta P3 (ajustes de presentación como espaciado y nombres de clases).

Existen reglas estrictas que impiden la resolución silenciosa: los marcadores de conflicto no se eliminan ni se ejecuta git add hasta que el usuario apruebe el plan o acepte explícitamente las recomendaciones. La herramienta se detiene en los conflictos en lugar de procesar archivos grandes de forma automática, y permite abortar la operación mediante git merge --abort o git rebase --abort. También enumera patrones a evitar, como seleccionar siempre --ours o --theirs en todo el repositorio, o ocultar una lista de conflictos dentro de un bloque largo de código sin incluir un resumen ejecutivo breve. Existen fragmentos de comandos opcionales y un modelo de mensaje de fusión disponibles en el archivo reference.md adjunto.

Preguntas frecuentes

¿Cuándo debo utilizar esta herramienta?

Cada vez que integres otra rama (generalmente main) en tu rama de características actual, o cuando git status muestre rutas no fusionadas tras una fusión o rebase. Se aplica a cualquier flujo de trabajo en equipo basado en Git, siendo las aplicaciones Flows/React un caso común.

¿Resuelve los conflictos automáticamente sin preguntarme?

No. Existen reglas estrictas que prohíben la resolución silenciosa: no se eliminarán los marcadores de conflicto ni se ejecutará git add hasta que aceptes el plan o indiques explícitamente que deseas seguir sus recomendaciones. La herramienta se detiene en los conflictos y los informa primero.

¿Cómo decide qué conflictos tratar primero?

Los conflictos se ordenan según su impacto, desde P0 (cambios estructurales o en el producto, como rutas eliminadas, características descartadas o cambios en datos y contratos de API) hasta P3 (ajustes de presentación como espaciado, nombres de clases y texto).

¿Qué información utiliza para analizar un conflicto antes de editarlo?

Utiliza el historial de conversaciones sobre qué contenidos se estaban integrando en la rama, señales del repositorio como un PRD.md o commits recientes, así como la información sobre quién es el propietario de los archivos, y los propios fragmentos de conflicto mediante git show :2:path para el contenido del nuestro y git show :3:path para el del otro.

¿Qué hago si solo quiero abortar la fusión?

La herramienta permite ejecutar git merge --abort o git rebase --abort según sea necesario, y advierte que perderás el estado de integración en curso asociado a esa operación.

Todos los archivos

2 archivosreference.md0.7 KBVerSKILL.md5.5 KBVer