A quién le sirve. Programadores que trabajan en equipo con Git y quieren ayuda para combinar cambios que chocan, con Microsoft Scout si su empresa tiene acceso o con otro agente de programación si no.
Qué hicieron
Cuando tras un git pull un archivo queda con marcas de conflicto, se lo señalas a Scout. Lee las marcas, compara las dos versiones del código y propone un archivo combinado para que lo revises. El artículo describe guardar y subir los cambios a una rama como otro flujo de Scout: revisa las diferencias, redacta el mensaje del cambio, crea la rama y la sube. Por defecto tú apruebas cada comando antes de que se ejecute.
Cómo salió
El artículo describe el flujo, pero no da resultados medidos, tiempos ni un ejemplo en un repositorio real. La resolución de fusiones ocupa solo unas frases y no dice cómo se comporta con conflictos complejos.
Conviene saber
Scout necesita acceso empresarial: inscripción en la vista previa Frontier, una política de dispositivo de Intune y licencias de Microsoft 365 Copilot y de GitHub Copilot Business o Enterprise. Con cuentas personales no se puede entrar.
Qué necesitas
- Acceso empresarial a Microsoft Scout: inscripción en la vista previa Frontier, una política de dispositivo de Intune y licencias de Microsoft 365 Copilot y de GitHub Copilot Business o Enterprise
- Un repositorio de Git con un conflicto de fusión
- El comando con el que se lanzan las pruebas del proyecto
- Alguien que revise el cambio antes de fusionarlo
Cómo hacerlo tú, paso a paso
- Comprueba con tu equipo de sistemas que tu empresa tiene acceso a Scout. Con cuentas personales no se puede entrar; si no hay acceso, usa otro agente de programación como Claude Code o Codex con el mismo prompt.
- Haz el git pull que provoca el conflicto y localiza los archivos con marcas de conflicto.
- Señala a Scout el archivo en conflicto y pega el prompt de la ficha con tus ramas y tu comando de pruebas.
- Lee la explicación de lo que cambió cada lado y la versión combinada que propone. Corrige lo que no te convenza.
- Cuando apruebes la versión, ejecuta las pruebas para confirmar que no se ha roto nada.
- Pide a Scout que revise las diferencias, redacte el mensaje del cambio, cree la rama y la suba. Por defecto aprobarás cada comando antes de que se ejecute.
- Abre una propuesta de cambios para que otra persona la revise antes de fusionar.
Mi repositorio en [ruta del repositorio] tiene conflictos de fusión tras unir [rama A] con [rama B]. Compara los dos lados de cada archivo en conflicto, explica qué cambió cada lado y propón una versión combinada para que yo la revise. Cuando yo la apruebe, ejecuta [comando de pruebas] para confirmar que no se ha roto nada, y detente para enseñarme los detalles del cambio antes de subirlo a [nombre de la rama].
Consejos
- Mantén la aprobación de cada comando. Es el ajuste por defecto y conviene no quitarlo.
- En los conflictos complejos, donde cada lado hace algo distinto, decide tú qué intención manda. El artículo no prueba cómo se comporta Scout con ellos.
- Ejecuta las pruebas antes de subir. Un archivo combinado puede compilar y aun así romper algo.
Preguntas frecuentes
¿Qué es un conflicto de fusión?
Ocurre cuando dos personas cambian la misma parte de un archivo y Git no sabe cuál conservar. Marca ambos lados y alguien debe decidir.
¿Puedo usarlo con una cuenta personal?
No, exige acceso empresarial. Sin él, un agente de programación como Claude Code o Codex puede hacer el mismo trabajo con el mismo prompt.
¿Puede subir el cambio sin que yo lo vea?
Por defecto no, porque aprobarás cada comando. Pídele además que se detenga y te enseñe los detalles antes de subirlo.
Fuentes
En el directorio desde el 3 de octubre de 2026.