Compara commits y ramas antes de revisar un cambio

Antes de revisar, decide qué pregunta quieres responder. «¿Qué cambió este commit?» y «¿Qué cambió esta rama desde que se separó?» pueden producir diffs diferentes incluso con los mismos nombres de rama.

¿Buscas una aplicación de Mac para leer cambios confirmados? Consulta el proceso y los límites del visor de diffs de Yenpo antes de seguir estos pasos.

Abre una comparación

Para revisar una rama feature frente a main, sigue estos pasos sustituyendo los nombres por los de tus ramas:

1. Abre el repositorio Git local y pulsa Compare Versions… en la barra lateral.
2. Cambia de Commit a Compare.
3. En From (base), selecciona Local branches y elige main. En To (head), selecciona Local branches y elige feature. Cada columna tiene su propio origen de ramas y campo de búsqueda.
4. Elige Since the branches split para el trabajo de feature, o Direct comparison para comparar ambos extremos. La siguiente sección explica por qué difieren.
5. Comprueba los nombres y los identificadores cortos de commit en el resumen. Usa Swap si la dirección es incorrecta y pulsa View Changes.
6. Selecciona un archivo en el árbol de cambios para leer su diff en línea.

Para usar origin/main, elige Remote branches en la columna From. Son referencias de seguimiento remoto guardadas en el repositorio local, no una vista en directo del servidor. Si necesitas commits remotos más recientes, actualiza con tu cliente Git habitual y vuelve a abrir el selector.

Yenpo fija la comparación a commits concretos. Si una rama avanza después, la revisión permanece en los commits elegidos. Para revisar el nuevo extremo, abre otra comparación.

Elige un modo

Pregunta	Modo	Compara
¿Qué cambió un commit?	Commit	Su primer padre → ese commit; un commit raíz se compara con un árbol vacío
¿En qué difieren ahora los extremos de dos ramas?	Direct comparison	Extremo de base → extremo de head
¿Qué cambió head desde la separación de las ramas?	Since the branches split	Merge base → extremo de head

Considera este historial:

      M1──M2  main
     /
O───X
     \
      F1──F2  feature

Una comparación directa de main → feature compara M2 con F2, por lo que incluye trabajo de ambos lados. Since the branches split compara X con F2, normalmente lo que necesitas para saber «qué añadió feature». No simula el merge final ni puede indicar si producirá conflictos.

Para un commit de merge, el modo Commit compara solo con el primer padre. Es una perspectiva del merge, no un diff contra cada padre; confirma que responde a tu pregunta.

Comprueba el par exacto de revisiones

Sitúa el cursor sobre la línea de revisiones encima del árbol de cambios para ver los identificadores completos. En Direct comparison, son los commits From y To seleccionados. En Since the branches split, la base lleva la etiqueta merge-base(...) y su identificador corresponde al ancestro común, no al extremo de la rama From.

Para comprobar esas mismas versiones en Git, ejecuta estos comandos de solo lectura desde el repositorio. Sustituye BASE_COMMIT_OID y HEAD_COMMIT_OID por los dos identificadores completos mostrados en Yenpo:

git show --no-patch --format='%h %s' BASE_COMMIT_OID HEAD_COMMIT_OID
git diff --stat BASE_COMMIT_OID HEAD_COMMIT_OID --

El primero identifica los commits; el segundo resume las diferencias entre sus árboles confirmados. Los archivos sin commit quedan fuera. Usa los identificadores anotados al comprobar una revisión antigua: los nombres de rama pueden apuntar ahora a commits nuevos.

Lee el diff en contexto

El árbol de archivos modificados abre diffs en línea de solo lectura. Los archivos de la comparación pueden estar junto a los actuales; comprueba la versión de cada pestaña antes de razonar sobre una llamada o prueba. Tu árbol de trabajo puede contener cambios ausentes del head seleccionado.

Para cada cambio de comportamiento, lee más allá de las líneas editadas:

1. Encuentra una llamada que pueda alcanzar el código nuevo.
2. Determina qué entrada o estado hace que se ejecute.
3. Sigue el valor devuelto, el error o el efecto secundario hasta quien llama.
4. Comprueba si una prueba existente entra realmente en ese estado.

Una prueba llamada «handles concurrent reads» puede limitarse a hacer dos llamadas consecutivas. Lee la preparación y las aserciones, no solo el nombre. La revisión de una caché de promesas lo muestra en la práctica.

Pide una revisión a AI Reader

Usa el botón Ask AI to review this comparison de la cabecera. Prepara un borrador con la comparación seleccionada adjunta, pero aún no envía la solicitud. Comprueba la etiqueta de comparación, ajusta el texto para especificar qué revisar y envíalo cuando esté listo. Si no has conectado un modelo, sigue primero Conecta un proveedor de modelos.

Por ejemplo:

Revisa este cambio buscando regresiones de cancelación y manejo de errores. Para cada hallazgo, indica la ubicación modificada, el estado que lo provoca, lo que vería el usuario y el código que lo respalda. Enumera por separado los problemas que ya existían en base.

Comprueba que cada desencadenante pueda ocurrir en los commits seleccionados. Si el orden no queda claro al leer el código, pide una reproducción o prueba concreta y ejecútala. Una prueba incluida en una respuesta aún no se ha ejecutado.

Cuando quieras corregir algo

Las conversaciones de comparación de Git siempre son de solo lectura. Para corregir el problema, inicia una conversación normal sobre el árbol de trabajo actual y activa Allow Edits. Conserva la comparación como referencia.

Después, lee el diff del árbol de trabajo y ejecuta las comprobaciones del proyecto. Detener una ejecución no revierte archivos ya escritos. Si había otros cambios previos, sepáralos de la corrección antes de decidir qué incluir en el commit.