Índice del artículo
En 30 segundos
Un diff es una comparación entre dos estados de un archivo o proyecto que muestra qué se ha añadido, eliminado o modificado.
Antes de aceptar el trabajo de un agente, el programa de IA que hace tareas con herramientas, revisa las diferencias respecto a una versión acordada. Comparar y comprobar son tareas distintas: ver las líneas cambiadas no demuestra que la web funcione.
Una condición de la carta cambia en Valladolid
Ejemplo ilustrativo: el propietario del restaurante ficticio La Encina, en Valladolid, decide servir la bebida por separado. Encarga cambiar esa condición en su carta web. En este supuesto, la carta está guardada en un archivo de texto. El responsable quiere comprobar que la propuesta expresa su decisión y que nadie ha alterado los alérgenos ni otras condiciones del menú.
Un diff se parece a la comparación entre versiones de un documento: te permite ver el antes y el después. La analogía ayuda a orientarte, aunque no implica que tenga las mismas funciones que el control de cambios de Word. Aquí se comparan dos estados concretos de un archivo. Puedes leer el texto anterior, el propuesto y las líneas cercanas que sitúan el cambio.
diff --git a/carta.md b/carta.md
--- a/carta.md
+++ b/carta.md
@@ -1,3 +1,3 @@
Restaurante La Encina
-Menú del día: bebida incluida.
+Menú del día: bebida no incluida.
Consulta los alérgenos en el local.Cómo leer los signos
Cabecera del archivo
Qué significa: Identifica qué archivos se comparan y cuál es el antes y el después.
Qué mirar: Que corresponda a la carta del encargo.
Menos (-) al inicio
Qué significa: Una línea de contenido que estaba antes y se elimina.
Qué mirar: Qué condición desaparece.
Más (+) al inicio
Qué significa: Una línea de contenido que se añade al estado posterior.
Qué mirar: Qué condición la sustituye.
Eliminación y adición parecidas
Qué significa: Pueden representar una modificación del mismo texto.
Qué mirar: El significado completo de ambas líneas.
Espacio al inicio
Qué significa: Es contexto que permanece igual en el fragmento.
Qué mirar: Qué rodea al cambio.
Cabecera con @@
Qué significa: Sitúa el fragmento dentro del archivo; no es contenido de la carta.
Qué mirar: Dónde ocurre la modificación.
Se explica el formato unificado habitual entre dos estados. Las cabeceras con tres signos identifican las versiones; no son líneas de la carta. Los indicadores pueden configurarse.
Lo decisivo está en el significado
En el ejemplo, la palabra «no» cambia la oferta que leerá el cliente. El signo más solo señala una incorporación: no significa que sea una mejora. El signo menos tampoco califica el contenido como erróneo. Si has pedido servir la bebida aparte, la nueva frase encaja con esa decisión. Si habías pedido mantenerla incluida, debes devolver la propuesta para que se corrija.
Lee la frase completa, no solo la palabra resaltada. El texto cercano ayuda a entender de qué menú se habla y qué aviso permanece. Eso te permite revisar la condición comercial que conoces. No te convierte en revisor técnico del resto del proyecto: si aparecen cambios de código que no entiendes, pide su explicación y que los compruebe quien mantiene la web.
Del encargo a la publicación
- Encargo
- Propuesta
- Lee el diff
- Comprueba
- Aprueba
- Publica
Cómo revisar la propuesta
Acuerda el punto de partida
Fija qué versiones se comparan antes de pedir la revisión. En el restaurante, señala la versión de la carta que habías aprobado y el cambio que esperas encontrar. Pide al agente las diferencias reales y la lista de archivos nuevos, además de una explicación de lo que salga del encargo. Un resumen escrito por el agente puede ayudarte, pero no sustituye esa comparación.
Comprueba el resultado
Abre la web de prueba con quien la mantiene. En este caso, revisad cómo se presenta la condición de la bebida y si la carta y sus enlaces siguen funcionando. El cambio se revisa en el lugar donde lo leerá el cliente, con el menú completo alrededor. Si el texto es correcto en el archivo pero aparece mal en la página, la tarea sigue pendiente.
Separa aprobar de publicar
Deja clara la decisión pendiente: el agente prepara la modificación y una persona autoriza su publicación cuando termina la revisión. En este encargo no tiene permiso para cambiar alérgenos, precios ni otros textos. Tampoco para subir el proyecto a una cuenta externa por su cuenta. Acordad y configurad esos límites en la forma de trabajar; consultar un diff no los impone automáticamente.
Un diff vacío puede dejar cambios fuera
La comparación tiene un alcance. Git, el programa que registra versiones de los archivos, distingue lo que estás editando de lo que has preparado para guardar. «Preparado» significa seleccionado para el próximo commit, una versión registrada del proyecto. No significa publicado. Un archivo puede tener una parte preparada y otras ediciones posteriores todavía sin preparar. Por eso dos consultas distintas pueden enseñar resultados distintos.
No des por intacto lo que no aparece. Una comparación puede omitir cambios ya preparados, archivos nuevos que Git aún no sigue o archivos excluidos por un filtro. Pide también el estado del proyecto y confirma si la vista está filtrada. La lista de archivos nuevos ayuda a completar la revisión; tampoco demuestra por sí sola que todo funcione ni incluye cualquier archivo ignorado por Git.
# Ediciones de trabajo frente a lo preparado
git diff
# Lo preparado frente al commit actual
git diff --staged
# Trabajo frente al commit actual, sin los archivos nuevos no seguidos
git diff HEAD
# Estado de archivos, incluidos los nuevos no ignorados
git status --short --untracked-files=allNo lo confundas con
Commit
Guarda una versión con los cambios preparados. El diff compara estados: consultarlo no guarda una versión nueva ni publica la web.
Repositorio
Conserva el proyecto y su historial. El diff es una vista de diferencias entre estados elegidos; no es el lugar donde se guarda esa historia.
Publicación
Pone el resultado a disposición del público. Revisar las líneas o guardar un commit local son pasos distintos de publicar la carta.
Dónde verlo sin convertirlo en otro proyecto
Puedes revisar en tu ordenador con Git, sin subir el proyecto a GitHub. VS Code, un editor para trabajar con archivos, incluye una vista de diferencias y separa los cambios preparados de los pendientes; para sus operaciones locales necesita Git instalado. Si ya trabajas con alguien que mantiene la web, pídele que te muestre la comparación en la herramienta que utiliza. No necesitas empezar eligiendo otro servicio.
En Claude Code, el agente de programación de Anthropic, el comando /diff permite revisar los cambios de la carpeta de trabajo. La vista actual puede incluir cambios de otras personas; la vista por turno muestra las ediciones de Claude de una intervención concreta. Comprueba qué vista estás mirando antes de atribuir los cambios al agente. Para seguir con esta forma de trabajar, tienes el curso Claude Code a fondo y las definiciones de commit, repositorio y rama.
Dudas sobre un diff, respuestas cortas
¿Por qué el diff sale vacío si he cambiado un archivo?
Puede que el cambio ya esté preparado para el próximo commit. La consulta básica compara los archivos de trabajo con lo preparado, así que no muestra esas diferencias. Revisa también la comparación de cambios preparados y confirma qué estados estás mirando antes de concluir que no hay modificaciones.
¿Por qué no aparece el archivo que acabo de crear?
Un archivo nuevo que Git todavía no sigue puede quedar fuera de la comparación con el commit actual. Consulta también el estado del proyecto y la lista de archivos nuevos no ignorados. Esa lista completa la revisión, pero no incluye cualquier archivo ignorado ni demuestra que el resultado funcione.
¿Basta con leer el diff para aprobar el trabajo del agente?
No. El diff muestra diferencias entre los estados elegidos; no comprueba el funcionamiento. Revisa si el cambio responde al encargo y comprueba el resultado con quien mantiene la web. Si aparecen modificaciones de código que no entiendes, pide explicación y revisión técnica antes de autorizar la publicación.
¿Sirve también para imágenes y otros archivos que no son texto?
Git puede detectar diferencias sin mostrar un desglose de líneas legible. Puede tratar un archivo como binario, es decir, sin compararlo como texto. Para revisar ese resultado, abre los archivos con una herramienta adecuada y comprueba el contenido. Un aviso de diferencias no explica por sí solo qué ha cambiado.
Fuentes
Fuentes oficiales, consultadas el 4 de noviembre de 2026
- Git · Comparaciones y alcance de git diff
- Git · Signos y cabeceras del formato de diferencias
- Pro Git · Archivos seguidos, preparación y commit
- Git · Atributos y diferencias de archivos binarios
- Git · Estado de archivos y archivos nuevos
- Microsoft · Control de versiones y diferencias en VS Code
- Anthropic · Comandos de Claude Code
- Anthropic · Revisión de cambios con diff
Cómo lo comprobamos. Fuentes consultadas el 4 de noviembre de 2026. Ciade no ha realizado una prueba operativa nueva de Git ni de VS Code, ni ha probado el ejemplo en una web real o la interfaz de `/diff` de Claude Code. Ciade utiliza Claude y Claude Code a diario desde España; ese uso previo no verifica todas las funciones descritas. Adapta los pasos de revisión con quien mantiene tu proyecto.
Qué ha cambiado.
- 4 de noviembre de 2026: Reescritura v2: se conserva la definición y se corrige la idea de que todo archivo ausente del diff permanece intacto. Se añaden alcance, ejemplo comentado, pasos de revisión y preguntas frecuentes.
Términos relacionados
Aprende a usar la IA en tu trabajo, con criterio.
El nivel 0 es gratis: cuarenta minutos para entender qué pedirle a la IA y qué revisar. El programa completo enseña a implementarla en tu propio negocio, tarea a tarea.
