¿Qué hace pull-changes-resolve-conflicts?
Flujo de trabajo estándar para extraer actualizaciones de main u otras ramas en proyectos con múltiples colaboradores (incluyendo aplicaciones Flows) sin descartar trabajo en silencio. Guía la obtención/fusión, requiere listar conflictos de fusión explícitamente, analizar 'nuestro' vs 'de ellos' usando el historial de conversación y el contexto del repositorio, presentar recomendaciones priorizadas y obtener respuestas del usuario antes de editar marcadores de conflicto o completar la fusión. Desencadenantes: pull main, merge main, merge origin, rebase, merge conflict, unmerged paths, both modified, integrate branch, sync with main, git merge abort, resolve conflicts, UU status, theirs vs ours, feat branch update.
Proceso del Flujo de Trabajo
- Detección del conflicto: Cuando un usuario intenta
pull main,merge main,merge origin,rebase, o se detectan estados comoboth modifiedoUU status, el agente inicia este flujo. - Listar conflictos: Se ejecuta
git statusygit diff --name-only --diff-filter=Upara listar todos los archivos con conflictos sin resolver. - Analizar 'nuestro' vs 'de ellos': Para cada archivo en conflicto, el agente examina:
- El historial de la conversación (commits locales, trabajos no confirmados, comentarios del usuario).
- El contexto del repositorio (commits de origen, ramas, responsable de los cambios).
- Las diferencias entre las versiones usando
git show :1:<archivo>,git show :2:<archivo>,git show :3:<archivo>(base, nuestra, de ellos).
- Presentar recomendaciones: El agente muestra una lista priorizada de opciones por archivo (por ejemplo: "Conservar nuestra versión", "Aceptar la de ellos", "Editar manualmente"), basada en el análisis contextual.
- Obtener respuesta del usuario: Antes de realizar cualquier edición o completar la fusión, el agente pregunta explícitamente al usuario cuál opción prefiere, o solicita instrucciones más específicas.
- Ejecutar la acción: Según la respuesta, el agente ejecuta comandos como
git checkout --ours <archivo>,git checkout --theirs <archivo>, o abre el editor para resolución manual. - Completar la fusión: Finalmente, si todos los conflictos están resueltos, el agente ejecuta
git add <archivo>ygit commit(ogit rebase --continue), notificando al usuario.
Desencadenantes (Triggers)
| Comando / Estado | Descripción |
|---|---|
pull main | Extraer cambios de la rama main |
merge main / merge origin | Fusionar con main u origen |
rebase | Rebase de la rama actual |
merge conflict / unmerged paths / both modified | Cuando git detecta conflictos |
UU status | Archivos con estado 'UU' (conflicto sin resolver) |
theirs vs ours | Análisis explícito de versiones |
feat branch update / integrate branch / sync with main | Actualización de rama de característica |
git merge abort / resolve conflicts | Comandos para abortar o resolver conflictos |
Buenas Prácticas
- No modificar marcadores de conflicto sin consultar: La edición directa de
<<<<<<<,=======,>>>>>>>solo debe realizarse después de obtener el consentimiento explícito del usuario. - Siempre listar todos los conflictos: No ocultar ni omitir archivos conflictivos; la transparencia es clave.
- Usar el contexto completo: Considerar tanto el historial local como el remoto para ofrecer recomendaciones informadas.
- Priorizar la seguridad: Si hay ambigüedad, preguntar en lugar de adivinar.
Ejemplo de Interacción
Usuario: "Fusiona origin/main en mi rama"
Asistente: Ejecuta `git fetch origin && git merge origin/main`
Asistente: Detecta conflicto en `src/app.ts` (ambos modificados).
Asistente: Muestra:
- Nuestra versión (local): introduce validación de entrada.
- Versión de ellos (remoto): corrige un error tipográfico en la misma línea.
Recomendación: Conservar ambas modificaciones (solución manual).
¿Qué deseas hacer?
Usuario: "Mezcla ambas, conservando la validación y el tipográfico corregido"
Asistente: Edita el archivo, ejecuta `git add src/app.ts`, y completa el merge con `git commit`.
Notas sobre Aplicaciones Flows
En aplicaciones Flows (plataforma CDF), este flujo se aplica de manera similar pero requiere verificar que el agente tenga permisos de lectura/escritura en los repositorios de configuración de Flows. Los conflictos en archivos YAML/JSON de Flows se tratan con el mismo proceso, aunque se recomienda precaución especial con estructuras de datos anidadas.
Documentación mantenida por el equipo de cognitedata. Para contribuciones, consulta el repositorio oficial.