Cómo comparar cambios con git diff

Cuando trabajas con Git, ver el estado del repositorio no basta: también necesitas entender qué ha cambiado exactamente. Ahí es donde entra git diff, el comando que te permite comparar versiones de un archivo, el área de trabajo, el índice o incluso dos commits entre sí.

Si ya has visto cómo consultar el estado del proyecto con git status y cómo revisar el historial con git log, el siguiente paso lógico es aprender a leer diferencias. Este comando es clave para revisar código, detectar errores antes de hacer commit y validar cambios con más confianza.

Qué es git diff y para qué sirve

git diff muestra diferencias entre dos estados de tu proyecto. En la práctica, te ayuda a responder preguntas como: “¿Qué modifiqué?”, “¿Qué tengo preparado para commit?” o “¿Qué cambió desde el último commit?”

Es una herramienta fundamental tanto si trabajas solo como si colaboras en equipo. Antes de enviar un cambio, revisar el diff evita commits innecesarios, bugs silenciosos y sorpresas durante una revisión de código.

Además, su utilidad no se limita al código fuente. También sirve para comparar archivos de configuración, documentación, scripts o cualquier texto versionado en Git.

Las tres comparaciones más habituales

Git trabaja con varios “espacios” de cambio. Entenderlos facilita mucho el uso de git diff:

Área de trabajo: los archivos que has modificado, pero aún no has preparado con git add.

Índice o staging area: los cambios que ya has añadido y están listos para incluirse en el próximo commit. Si necesitas repasar cómo funciona ese paso, puedes volver a cómo añadir archivos al repositorio con git add.

Repositorio local: el historial de commits ya guardados en tu rama actual.

Uso básico de git diff

El comportamiento más simple de git diff es mostrar las diferencias entre el área de trabajo y el índice, es decir, lo que todavía no has preparado para commit.

# Muestra los cambios no preparados para commit
git diff

Este resultado suele incluir líneas eliminadas y añadidas. Git marca los archivos modificados y detalla el contenido exacto que se ha cambiado, línea por línea.

Si quieres una visión rápida, este comando es perfecto para verificar que no has tocado nada que no debías antes de pasar esos cambios al staging area.

Ejemplo de diff en un archivo

diff --git a/app.js b/app.js
index 3b18e7a..4f2d1c1 100644
--- a/app.js
+++ b/app.js
@@ -10,7 +10,7 @@ function saludar() {
-  console.log("Hola mundo");
+  console.log("Hola Git");
 }

En este formato, la línea que empieza por – representa lo que se eliminó y la que empieza por + lo que se añadió. La cabecera muestra el archivo comparado y los fragmentos alrededor del cambio.

Comparar cambios ya preparados para commit

Una de las dudas más comunes es cómo revisar lo que ya has añadido con git add. Para ello, se usa una variante específica:

# Muestra los cambios staged, es decir, listos para commit
git diff --cached

En algunas versiones también verás git diff –staged, que funciona con el mismo propósito. Ambas opciones son útiles para inspeccionar exactamente lo que entrará en el próximo commit.

Este paso encaja muy bien con un flujo de trabajo limpio: primero revisas el estado con git status, luego inspeccionas el diff y, cuando todo está listo, haces el commit.

Por qué conviene revisar el staging area

Muchos errores de flujo ocurren aquí. Puedes haber añadido un archivo por accidente, olvidado una línea importante o preparado cambios incompletos.

Revisar el diff del staging area te permite detectar esos problemas antes de grabar el historial. Es una práctica simple, pero muy valiosa en equipos donde la calidad del commit importa.

Comparar con commits concretos

Git diff no solo compara trabajo pendiente. También puedes usarlo para contrastar dos puntos concretos del historial. Esto es especialmente útil cuando quieres saber qué cambió entre una versión y otra.

# Compara dos commits por su hash
git diff commit1 commit2

También puedes comparar un commit con el estado actual de una rama, o con el último commit de la referencia que estés analizando. Este enfoque es útil para auditoría técnica, depuración y revisiones de cambios más amplias.

Qué debes tener en cuenta al comparar commits

Los hashes de commit los obtienes con git log. Esa combinación, git log para localizar versiones y git diff para ver diferencias, forma una pareja esencial en Git.

Si trabajas con ramas, puedes comparar el contenido de una rama con otra, o estudiar qué se ha incorporado desde una evolución concreta del proyecto. Es una manera muy práctica de entender la historia del código sin abrir el editor.

Opciones útiles para leer mejor los cambios

En proyectos medianos o grandes, el diff puede ser largo. Por eso Git ofrece opciones para afinar la salida y hacerla más legible.

Ver solo los nombres de archivos

# Lista solo los archivos modificados
git diff --name-only

Esta variante es ideal cuando no necesitas el detalle línea por línea y solo quieres identificar qué ficheros han sido tocados.

Ver un resumen de cambios

# Muestra una vista resumida de altas, bajas y modificaciones
git diff --stat

El resumen estadístico ayuda a evaluar rápidamente el tamaño de un cambio, algo útil antes de abrir una revisión o compartir una rama con el equipo.

Ignorar diferencias de espacio en blanco

# Reduce el ruido por espacios o tabulaciones
git diff -w

Esta opción resulta práctica cuando estás revisando cambios en archivos donde el formateo ha introducido ruido, aunque conviene usarla con criterio para no pasar por alto diferencias importantes.

Consejos para interpretar mejor un diff

Leer diffs con soltura es una habilidad muy útil en desarrollo. Con el tiempo, deja de ser una salida técnica y se convierte en una herramienta de control de calidad.

Un consejo básico es revisar el contexto, no solo la línea eliminada o añadida. A veces el problema no está en la modificación en sí, sino en cómo afecta a la lógica cercana.

También conviene comparar diffs pequeños. Cuanto más acotado esté el cambio, más fácil será entenderlo y validarlo. Por eso muchos equipos prefieren commits breves y temáticos, en lugar de acumulaciones grandes de cambios distintos.

Otra práctica recomendable es combinar git diff con git status y git log. Esa secuencia te da una visión completa: qué cambió, qué está preparado y dónde encaja en el historial.

Flujo de trabajo recomendado

Un flujo sencillo y eficaz podría ser este: modificas archivos, revisas el estado, comparas con git diff, añades con git add, vuelves a comprobar el diff staged y finalmente haces el commit.

# 1. Ver estado del repositorio
git status

# 2. Revisar cambios no preparados
git diff

# 3. Añadir archivos al staging
git add archivo.js

# 4. Revisar cambios preparados
git diff --cached

# 5. Crear el commit
git commit -m "Ajusta la lógica de validación"

Este hábito te ayuda a mantener un historial más limpio y reduce la probabilidad de subir cambios incompletos o incorrectos. Es una base sólida para trabajar con ramas, revisiones y pull requests.

Conclusión

git diff es una de las herramientas más importantes de Git porque convierte cambios invisibles en información clara y verificable. Saber usarlo bien te da más control sobre tu código, mejora la calidad de tus commits y te ayuda a detectar errores antes de que lleguen a producción.

Si ya dominas la creación de commits, el uso de git add y la lectura del historial con git log, este comando será uno de tus mejores aliados en el día a día.

Fuentes y lecturas recomendadas

Documentación oficial de git diff

Pro Git, libro oficial de Git

Documentación de GitHub sobre flujos de trabajo con Git

Xose de la Paz

Más de 20 años transformando pasión en profesión. Experto en desarrollo Full Stack con una visión integral que abarca desde la gestión de servidores y redes hasta el diseño de interfaz. Soy un "todoterreno" tecnológico que cree en el aprendizaje continuo y la visión global de los proyectos. Entre despliegue y despliegue, me pierdo por el mundo con mi cámara al hombro.

Web | LinkedIn