Git Diff — El hábito de verificar antes de confirmar

Al finalizar este tema

Podrás distinguir por qué es importante el hábito de verificar los cambios con git diff y diferenciar qué opción muestra qué estado.

El momento en que piensas "¿eh?" después de confirmar

Modificaste el código y realizaste git add . → git commit. Sin embargo, al hacer push, descubriste que quedaban 3 depuradores console.log. También se subió el archivo .env. La clave de API quedó expuesta en GitHub.

El punto común en estos incidentes es que no se verificó qué se iba a incluir antes de confirmar. git diff es el comando que realiza esta verificación.

git diff — Cambios aún no indexados

git diff

Este comando muestra los cambios que has modificado en el directorio de trabajo, pero aún no has hecho commit con git add.

- const API_URL = "https://api.example.com";
+ const API_URL = "https://api.production.com";

La línea roja - corresponde al contenido anterior, y la línea verde + al nuevo contenido. Es posible ver de un vistazo qué archivo ha cambiado y en qué línea.

git diff --staged — Cambios en el área de preparación

git diff --staged

Muestra solo los cambios que se han puesto en el área de staging con git add. Es el comando para verificar exactamente qué se incluirá si realizas un commit ahora.

Para entender esto, es necesario conocer las 3 áreas de Git:

Directorio de trabajo  →  Área de staging  →  Historial de commits
    (edición)              (git add)           (git commit)

git diff       git diff --staged
 ↑ aquí           ↑ aquí

git diff muestra la diferencia entre el directorio de trabajo y la zona de preparación (staging), mientras que git diff --staged muestra la diferencia entre la zona de preparación y el último commit.

Comparación entre commits

También es posible comparar commits específicos:

git diff HEAD~3..HEAD

Muestra completamente los cambios realizados en los últimos tres commits.

git diff main..feature-branch

Muestra la diferencia entre las ramas main y feature-branch. Verificarla antes de crear una PR (Pull Request) permite revisar el contenido que verá el revisor.

Vista por archivo

Si el diff completo es demasiado largo, puedes ver solo archivos específicos:

git diff src/api/handler.js
git diff --staged package.json

Al añadir la opción --stat, solo se muestra un resumen de los archivos que han cambiado:

git diff --stat

src/api/handler.js    | 12 ++++++------
 src/utils/format.js   |  3 ++-
 package.json          |  1 +
 3 files changed, 9 insertions(+), 7 deletions(-)

Puede identificar rápidamente la lista de archivos y el alcance de los cambios. Es recomendable revisar primero este resumen para determinar el ámbito antes de leer todo en detalle.

Hábito profesional: 3 pasos antes del commit

Los desarrolladores experimentados siguen este orden antes de realizar un commit:

git status          # 1. Comprobar qué archivos cambiaron
git diff            # 2. Revisar los cambios antes del staging
git add <archivos>  # 3. Añadir selectivamente solo lo necesario al staging
git diff --staged   # 4. Revisión final de lo que entrará en el commit
git commit          # 5. Crear el commit

No se trata de subir todo con git add ., sino que lo fundamental es revisar los archivos uno por uno antes de subirlos. Esto evita que se incluyan accidentalmente código de depuración, valores codificados para pruebas o archivos sensibles como .env.

Diff en herramientas de interfaz gráfica de usuario (GUI)

Las herramientas de GUI como el panel Control de origen de VS Code, GitKraken y GitHub Desktop también ejecutan internamente git diff. Muestran los cambios con colores en la pantalla y permiten realizar el seguimiento (staging) o dejar de seguirlos línea por línea.

Independientemente de la herramienta que se utilice, el principio es el mismo: verificar visualmente qué contenido se incluye antes de confirmar (commit).

Concepto clave

git diff es el comando para revisar los cambios antes de confirmarlos. git diff muestra los cambios que han sido des-seguidos, mientras que git diff --staged muestra los cambios que están seguidos. El hábito de realizar confirmaciones sin revisión es la causa de fugas de .env y de la permanencia de código de depuración.