Sinopsis
git add [-p] [-A] [-u] [--] [<pathspec>...]Descripción
El comando git add mueve cambios de tu árbol de trabajo al área de staging (también llamada el index). El área de staging es una instantánea de lo que irá al próximo commit. Al stagear cambios explícitamente, Git te permite elaborar commits que contienen exactamente el trabajo que quieres registrar, incluso si tu árbol de trabajo tiene otras ediciones no relacionadas en progreso.
git add puede stagear archivos enteros, partes de archivos (con -p) o directorios. No hace commit de nada; solo actualiza el index. El flujo más común es: editar, git status, git add, git commit. Dominar git add, especialmente sus modos interactivos, es una de las mejores formas de hacer tu historial de commits legible y fácil de revisar.
En el uso diario, git add se integra estrechamente con alias de shell, plugins de editor e integración continua. Los usuarios avanzados a menudo añaden alias que combinan los flags que siempre pasan, o envuelven el comando en scripts que hacen cumplir convenciones de equipo. El formato de salida puede personalizarse vía configuración de Git: formatos pretty, esquemas de color y comportamiento del paginador son ajustables. Cuando algo sale mal, el primer paso de diagnóstico suele ser re-ejecutar el comando con GIT_TRACE=1 en el entorno, lo que revela las llamadas plumbing subyacentes. Para situaciones inusuales, la salida de --help (git add --help) abre la página de manual completa con detalles de cada opción, incluyendo aquellas raramente usadas en flujos casuales pero esenciales para depuración o scripting a escala.
Entender cómo git add interactúa con el resto del modelo de datos de Git (la base de datos de objetos, el index, las refs y el árbol de trabajo) rinde dividendos. Cada comando opera sobre algún subconjunto de estas piezas, y saber cuáles toca ayuda a predecir resultados y a recuperarse de errores. Leer la documentación oficial de Git junto con práctica práctica en un repositorio desechable es la forma más rápida de internalizar los matices. La mayoría de problemas de producción con Git provienen de una de tres causas: comportamiento predeterminado sorprendente, operaciones de red parciales, o reescribir historial que ya se compartió. Un modelo mental funcional de los efectos secundarios de git add ayuda a evitar las tres.
Opciones comunes
| Opción | Descripción |
|---|---|
-A, --all | Stagea todos los cambios en el árbol de trabajo, incluidas eliminaciones y nuevos archivos. |
-u, --update | Stagea modificaciones y eliminaciones solo de archivos rastreados; ignora archivos nuevos. |
-p, --patch | Elige interactivamente hunks de cambios para stagear. |
-n, --dry-run | Muestra lo que se stagearía sin stagear realmente. |
-f, --force | Añade archivos incluso si coinciden con .gitignore. |
-i, --interactive | Abre una interfaz dirigida por menú para stagear. |
--intent-to-add / -N | Registra una intención de añadir un archivo para que aparezca su diff. |
Ejemplos
git add README.md src/main.c
# Stagea dos archivos específicos
git add -A
# Stagea todo: archivos nuevos, modificados y eliminados
git add -p
# Revisa y stagea fragmentos uno por uno interactivamente
git add 'src/**/*.js'
# Stagea todos los archivos JavaScript bajo src usando un pathspecErrores comunes
Ejecutar git add . a ciegas a menudo stagea archivos que no pretendías: archivos de log, artefactos de build, claves secretas. Usa git status primero y considera -p para cambios sensibles. Otra confusión común: git add -u no recogerá nuevos archivos, mientras que git add . sí. Después de stagear, si cambias un archivo de nuevo, esas ediciones posteriores no están staged hasta que vuelvas a ejecutar git add.
Comandos relacionados
git commit, git status, git restore, git reset