Resolver conflictos

Cuando una operación de git para a mitad de camino, el panel de revisión te lo cuenta. Nace una franja en la parte de arriba, roja si todavía hay archivos en conflicto, ámbar si ya no los hay. No hace falta que la pidas. La franja aparece sola, y desaparece sola cuando la operación termina.

​

Qué detecta

TYBA mira marcadores en el git-dir de ese árbol, en este orden: Ninguno de ellos, ninguna franja. Al lado del título vienen los dos lados: main ← feature. El ours es tu branch (durante un rebase, el HEAD está suelto, así que lee el head-name que la propia operación dejó). El theirs es el otro lado — el nombre cuando git sabe decirlo, un SHA corto cuando no.

​

La lista de archivos

Cada archivo en conflicto es una línea, con el código XY de git al lado — UU (los dos cambiaron), AA (los dos añadieron), DD, AU… El código está ahí porque cambia lo que significa “elegir un lado”. Cada línea tiene cuatro acciones: Elegir un lado es el archivo entero. No es por hunk, no es por línea. Es la herramienta correcta para un lockfile, un snapshot, un archivo generado — y la herramienta equivocada para el src/ que tiene intención de los dos lados. Si el archivo ya no está en conflicto cuando haces clic — porque la lista envejeció, porque el agente lo resolvió mientras tanto — la acción se rechaza: “is not in conflict — the list may have refreshed.” Ninguna acción escribe a ciegas.

​

Resolver con el agente

El botón a la derecha de la franja le pasa el problema al agente. Monta un prompt con la operación, los dos lados, la lista de archivos con sus códigos, y una instrucción explícita de preservar la intención de los dos lados y quitar los marcadores. Entonces:

• ¿Hay una sesión de agente viva en la carpeta? El prompt va a su composer.
• ¿No? TYBA levanta una sesión de agente en esa carpeta — con sandbox y con el gate de aprobación — y el prompt va a su composer.

El final del prompt cambia según la operación:

• Merge — el agente resuelve, hace git add, y para. No concluye el commit del merge. Quien revisa la resolución y commitea eres tú.
• Rebase / cherry-pick — el agente resuelve y ejecuta --continue hasta que la operación termina, sin crear commits más allá de los que la propia operación replica.

​

El último paso es tuyo

¿Resolviste todo? La franja no desaparece — se pone ámbar y dice:

Conflicts resolved — finish the operation (commit / —continue).

Eso no es un bug: TYBA no concluye la operación por ti. Detecta, te deja elegir lado por lado, marca lo resuelto. El git commit del merge, el git rebase --continue, el git cherry-pick --continue son tuyos, en la terminal de la sesión. Es el último acto deliberado antes de que el historial cambie de forma. Cuando la operación termine, el marcador desaparece del git-dir y la franja desaparece de la pantalla.

​

Qué no existe

• Concluir la operación con un botón. Ni commit de merge, ni --continue.
• Abortar con un botón. git merge --abort es en la terminal.
• Editor de merge de tres vías. Las opciones son: un lado entero, o tu editor.
• Elegir el lado por hunk. Es el archivo entero.
• La franja mientras exploras otra branch. Explorando una branch en el picker, el panel esconde la franja — lo que está en pantalla no es el árbol conflictuado. Vuelve a la sesión y reaparece.

​

Ver también