<\/p>\n
Aprende a comparar cambios con git diff, interpretar el output y revisar modificaciones en archivos, commits y ramas.<\/p>\n
Cuando trabajas con Git, ver el estado del repositorio no basta: tambi\u00e9n necesitas entender qu\u00e9 ha cambiado exactamente<\/strong>. Ah\u00ed es donde entra git diff<\/strong>, el comando que te permite comparar versiones de un archivo, el \u00e1rea de trabajo, el \u00edndice o incluso dos commits entre s\u00ed.<\/p>\n Si ya has visto c\u00f3mo consultar el estado del proyecto con git status<\/a> y c\u00f3mo revisar el historial con git log<\/a>, el siguiente paso l\u00f3gico es aprender a leer diferencias. Este comando es clave para revisar c\u00f3digo, detectar errores antes de hacer commit y validar cambios con m\u00e1s confianza.<\/p>\n git diff<\/strong> muestra diferencias entre dos estados de tu proyecto. En la pr\u00e1ctica, te ayuda a responder preguntas como: \u201c\u00bfQu\u00e9 modifiqu\u00e9?\u201d, \u201c\u00bfQu\u00e9 tengo preparado para commit?\u201d o \u201c\u00bfQu\u00e9 cambi\u00f3 desde el \u00faltimo commit?\u201d<\/p>\n 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\u00f3n de c\u00f3digo.<\/p>\n Adem\u00e1s, su utilidad no se limita al c\u00f3digo fuente. Tambi\u00e9n sirve para comparar archivos de configuraci\u00f3n, documentaci\u00f3n, scripts o cualquier texto versionado en Git.<\/p>\n Git trabaja con varios \u201cespacios\u201d de cambio. Entenderlos facilita mucho el uso de git diff<\/strong>:<\/p>\n \u00c1rea de trabajo<\/strong>: los archivos que has modificado, pero a\u00fan no has preparado con git add.<\/p>\n \u00cdndice o staging area<\/strong>: los cambios que ya has a\u00f1adido y est\u00e1n listos para incluirse en el pr\u00f3ximo commit. Si necesitas repasar c\u00f3mo funciona ese paso, puedes volver a c\u00f3mo a\u00f1adir archivos al repositorio con git add<\/a>.<\/p>\n Repositorio local<\/strong>: el historial de commits ya guardados en tu rama actual.<\/p>\n El comportamiento m\u00e1s simple de git diff<\/strong> es mostrar las diferencias entre el \u00e1rea de trabajo y el \u00edndice, es decir, lo que todav\u00eda no has preparado para commit.<\/p>\n Este resultado suele incluir l\u00edneas eliminadas y a\u00f1adidas. Git marca los archivos modificados y detalla el contenido exacto que se ha cambiado, l\u00ednea por l\u00ednea.<\/p>\n Si quieres una visi\u00f3n r\u00e1pida, este comando es perfecto para verificar que no has tocado nada que no deb\u00edas antes de pasar esos cambios al staging area.<\/p>\n En este formato, la l\u00ednea que empieza por –<\/strong> representa lo que se elimin\u00f3 y la que empieza por +<\/strong> lo que se a\u00f1adi\u00f3. La cabecera muestra el archivo comparado y los fragmentos alrededor del cambio.<\/p>\n Una de las dudas m\u00e1s comunes es c\u00f3mo revisar lo que ya has a\u00f1adido con git add<\/strong>. Para ello, se usa una variante espec\u00edfica:<\/p>\n En algunas versiones tambi\u00e9n ver\u00e1s git diff –staged<\/strong>, que funciona con el mismo prop\u00f3sito. Ambas opciones son \u00fatiles para inspeccionar exactamente lo que entrar\u00e1 en el pr\u00f3ximo commit.<\/p>\n Este paso encaja muy bien con un flujo de trabajo limpio: primero revisas el estado con git status<\/a>, luego inspeccionas el diff y, cuando todo est\u00e1 listo, haces el commit.<\/p>\n Muchos errores de flujo ocurren aqu\u00ed. Puedes haber a\u00f1adido un archivo por accidente, olvidado una l\u00ednea importante o preparado cambios incompletos.<\/p>\n Revisar el diff del staging area te permite detectar esos problemas antes de grabar el historial. Es una pr\u00e1ctica simple, pero muy valiosa en equipos donde la calidad del commit importa.<\/p>\n Git diff no solo compara trabajo pendiente. Tambi\u00e9n puedes usarlo para contrastar dos puntos concretos del historial. Esto es especialmente \u00fatil cuando quieres saber qu\u00e9 cambi\u00f3 entre una versi\u00f3n y otra.<\/p>\n Tambi\u00e9n puedes comparar un commit con el estado actual de una rama, o con el \u00faltimo commit de la referencia que est\u00e9s analizando. Este enfoque es \u00fatil para auditor\u00eda t\u00e9cnica, depuraci\u00f3n y revisiones de cambios m\u00e1s amplias.<\/p>\n Los hashes de commit los obtienes con git log<\/a>. Esa combinaci\u00f3n, git log<\/strong> para localizar versiones y git diff<\/strong> para ver diferencias, forma una pareja esencial en Git.<\/p>\n Si trabajas con ramas, puedes comparar el contenido de una rama con otra, o estudiar qu\u00e9 se ha incorporado desde una evoluci\u00f3n concreta del proyecto. Es una manera muy pr\u00e1ctica de entender la historia del c\u00f3digo sin abrir el editor.<\/p>\n En proyectos medianos o grandes, el diff puede ser largo. Por eso Git ofrece opciones para afinar la salida y hacerla m\u00e1s legible.<\/p>\n Esta variante es ideal cuando no necesitas el detalle l\u00ednea por l\u00ednea y solo quieres identificar qu\u00e9 ficheros han sido tocados.<\/p>\n El resumen estad\u00edstico ayuda a evaluar r\u00e1pidamente el tama\u00f1o de un cambio, algo \u00fatil antes de abrir una revisi\u00f3n o compartir una rama con el equipo.<\/p>\n Esta opci\u00f3n resulta pr\u00e1ctica cuando est\u00e1s revisando cambios en archivos donde el formateo ha introducido ruido, aunque conviene usarla con criterio para no pasar por alto diferencias importantes.<\/p>\n Leer diffs con soltura es una habilidad muy \u00fatil en desarrollo. Con el tiempo, deja de ser una salida t\u00e9cnica y se convierte en una herramienta de control de calidad.<\/p>\n Un consejo b\u00e1sico es revisar el contexto, no solo la l\u00ednea eliminada o a\u00f1adida. A veces el problema no est\u00e1 en la modificaci\u00f3n en s\u00ed, sino en c\u00f3mo afecta a la l\u00f3gica cercana.<\/p>\n Tambi\u00e9n conviene comparar diffs peque\u00f1os. Cuanto m\u00e1s acotado est\u00e9 el cambio, m\u00e1s f\u00e1cil ser\u00e1 entenderlo y validarlo. Por eso muchos equipos prefieren commits breves y tem\u00e1ticos, en lugar de acumulaciones grandes de cambios distintos.<\/p>\n Otra pr\u00e1ctica recomendable es combinar git diff<\/strong> con git status<\/strong> y git log<\/strong>. Esa secuencia te da una visi\u00f3n completa: qu\u00e9 cambi\u00f3, qu\u00e9 est\u00e1 preparado y d\u00f3nde encaja en el historial.<\/p>\n Un flujo sencillo y eficaz podr\u00eda ser este: modificas archivos, revisas el estado, comparas con git diff, a\u00f1ades con git add, vuelves a comprobar el diff staged y finalmente haces el commit.<\/p>\n Este h\u00e1bito te ayuda a mantener un historial m\u00e1s limpio y reduce la probabilidad de subir cambios incompletos o incorrectos. Es una base s\u00f3lida para trabajar con ramas, revisiones y pull requests.<\/p>\n git diff<\/strong> es una de las herramientas m\u00e1s importantes de Git porque convierte cambios invisibles en informaci\u00f3n clara y verificable. Saber usarlo bien te da m\u00e1s control sobre tu c\u00f3digo, mejora la calidad de tus commits y te ayuda a detectar errores antes de que lleguen a producci\u00f3n.<\/p>\n Si ya dominas la creaci\u00f3n de commits, el uso de git add<\/a> y la lectura del historial con git log<\/a>, este comando ser\u00e1 uno de tus mejores aliados en el d\u00eda a d\u00eda.<\/p>\n Documentaci\u00f3n oficial de git diff<\/a><\/p>\nQu\u00e9 es git diff y para qu\u00e9 sirve<\/h2>\n
Las tres comparaciones m\u00e1s habituales<\/h3>\n
Uso b\u00e1sico de git diff<\/h2>\n
# Muestra los cambios no preparados para commit\ngit diff<\/code><\/pre>\nEjemplo de diff en un archivo<\/h3>\n
diff --git a\/app.js b\/app.js\nindex 3b18e7a..4f2d1c1 100644\n--- a\/app.js\n+++ b\/app.js\n@@ -10,7 +10,7 @@ function saludar() {\n- console.log(\"Hola mundo\");\n+ console.log(\"Hola Git\");\n }<\/code><\/pre>\nComparar cambios ya preparados para commit<\/h2>\n
# Muestra los cambios staged, es decir, listos para commit\ngit diff --cached<\/code><\/pre>\nPor qu\u00e9 conviene revisar el staging area<\/h3>\n
Comparar con commits concretos<\/h2>\n
# Compara dos commits por su hash\ngit diff commit1 commit2<\/code><\/pre>\nQu\u00e9 debes tener en cuenta al comparar commits<\/h3>\n
Opciones \u00fatiles para leer mejor los cambios<\/h2>\n
Ver solo los nombres de archivos<\/h3>\n
# Lista solo los archivos modificados\ngit diff --name-only<\/code><\/pre>\nVer un resumen de cambios<\/h3>\n
# Muestra una vista resumida de altas, bajas y modificaciones\ngit diff --stat<\/code><\/pre>\nIgnorar diferencias de espacio en blanco<\/h3>\n
# Reduce el ruido por espacios o tabulaciones\ngit diff -w<\/code><\/pre>\nConsejos para interpretar mejor un diff<\/h2>\n
Flujo de trabajo recomendado<\/h2>\n
# 1. Ver estado del repositorio\ngit status\n\n# 2. Revisar cambios no preparados\ngit diff\n\n# 3. A\u00f1adir archivos al staging\ngit add archivo.js\n\n# 4. Revisar cambios preparados\ngit diff --cached\n\n# 5. Crear el commit\ngit commit -m \"Ajusta la l\u00f3gica de validaci\u00f3n\"<\/code><\/pre>\nConclusi\u00f3n<\/h2>\n
Fuentes y lecturas recomendadas<\/h3>\n