{"id":1389,"date":"2026-07-27T10:03:45","date_gmt":"2026-07-27T08:03:45","guid":{"rendered":"https:\/\/vermiip.es\/blog\/?p=1389"},"modified":"2026-07-27T10:04:41","modified_gmt":"2026-07-27T08:04:41","slug":"como-anadir-archivos-al-repositorio-con-git-add","status":"publish","type":"post","link":"https:\/\/vermiip.es\/blog\/como-anadir-archivos-al-repositorio-con-git-add\/","title":{"rendered":"C\u00f3mo a\u00f1adir archivos al repositorio con git add"},"content":{"rendered":"

Aprende a usar git add para a\u00f1adir archivos al repositorio, preparar cambios y entender el \u00e1rea de staging con ejemplos claros y pr\u00e1cticos.<\/p>\n

Despu\u00e9s de crear o clonar un repositorio de Git, el siguiente paso natural es empezar a incorporar cambios. Aqu\u00ed es donde entra en juego git add<\/strong>, un comando esencial para preparar archivos antes de crear un commit. Si vienes de ver c\u00f3mo crear tu primer repositorio con git init<\/a> o c\u00f3mo trabajar con un proyecto existente mediante git clone<\/a>, este art\u00edculo te ayudar\u00e1 a dar el siguiente paso con confianza.<\/p>\n

Entender bien git add<\/strong> no solo te evita errores, tambi\u00e9n te da m\u00e1s control sobre qu\u00e9 cambios entran en la historia del proyecto y cu\u00e1les no. En otras palabras, es el puente entre editar archivos en tu equipo y llevar esos cambios al flujo de trabajo de Git.<\/p>\n

Qu\u00e9 hace realmente git add<\/h2>\n

Una duda muy com\u00fan es pensar que git add<\/strong> \u201csube\u201d archivos al repositorio. En realidad, no los sube todav\u00eda. Lo que hace es mover los cambios al \u00e1rea de preparaci\u00f3n<\/strong> o staging area<\/em>, donde Git los deja listos para ser confirmados con un commit.<\/p>\n

Ese matiz es importante. Git trabaja con tres estados principales: los archivos en tu directorio de trabajo, los cambios preparados y el historial de commits. git add<\/strong> conecta el primero con el segundo, pero todav\u00eda no guarda nada en la l\u00ednea temporal del proyecto.<\/p>\n

El flujo b\u00e1sico de trabajo<\/h3>\n

Un ciclo t\u00edpico suele verse as\u00ed:<\/p>\n

# 1. Editas uno o varios archivos\n# 2. Preparas los cambios con git add\ngit add archivo.html\n\n# 3. Creas el commit con mensaje descriptivo\ngit commit -m \"A\u00f1ade la p\u00e1gina de contacto\"\n<\/code><\/pre>\n
Este patr\u00f3n es la base del control de versiones. Si ya vienes de aprender qu\u00e9 es Git<\/a>, reconocer\u00e1s que una buena gesti\u00f3n del staging mejora mucho la calidad de los commits.<\/p>\n
Preparar archivos con git add<\/h2>\n
La forma m\u00e1s simple de usar el comando es indicar el nombre del archivo que quieres a\u00f1adir al staging:<\/p>\n
git add estilo.css\ngit add index.html\n<\/code><\/pre>\n
Con esto, Git registra esas modificaciones para el pr\u00f3ximo commit. Si un archivo se modifica varias veces antes de confirmar, solo se preparar\u00e1 la versi\u00f3n actual que est\u00e9 en el momento de ejecutar el comando.<\/p>\n
Tambi\u00e9n puedes a\u00f1adir varios archivos de una sola vez, lo que resulta \u00fatil cuando trabajas en una funcionalidad peque\u00f1a o en un ajuste que afecta a varias partes del proyecto.<\/p>\n
A\u00f1adir toda la carpeta o todos los cambios<\/h3>\n
Cuando ya controlas el flujo b\u00e1sico, puedes usar opciones m\u00e1s amplias. La m\u00e1s conocida es:<\/p>\n
git add .\n<\/code><\/pre>\n
Este comando a\u00f1ade al \u00e1rea de staging todos los archivos nuevos y modificados dentro del directorio actual y sus subcarpetas. Es muy pr\u00e1ctico, pero conviene usarlo con atenci\u00f3n para no incluir cambios que a\u00fan no quieres versionar.<\/p>\n
Otra variante habitual es:<\/p>\n
git add -A\n<\/code><\/pre>\n
Esta opci\u00f3n prepara todos los cambios del repositorio, incluidos archivos eliminados. Es especialmente \u00fatil cuando quieres capturar el estado completo de una rama antes de hacer un commit importante.<\/p>\n
diferencias entre git add, git commit y git status<\/h2>\n
Si est\u00e1s empezando, es f\u00e1cil confundir estos comandos. La regla r\u00e1pida ser\u00eda esta: git add<\/strong> prepara, git commit<\/strong> guarda y git status<\/strong> te informa.<\/p>\n
git status<\/strong> es tu mejor aliado para no perder de vista qu\u00e9 est\u00e1 pasando. Antes y despu\u00e9s de usar git add<\/strong>, revisarlo te ayuda a entender qu\u00e9 archivos est\u00e1n sin seguimiento, cu\u00e1les fueron modificados y cu\u00e1les ya est\u00e1n listos para el commit.<\/p>\n
git status\ngit add app.js\ngit status\ngit commit -m \"Corrige la validaci\u00f3n del formulario\"\n<\/code><\/pre>\n
Este peque\u00f1o h\u00e1bito mejora mucho tu precisi\u00f3n. En equipos de desarrollo, un staging bien revisado reduce commits demasiado grandes o mezclados, algo que suele complicar revisiones y fusiones posteriores.<\/p>\n
Usar git add con archivos nuevos, modificados y eliminados<\/h2>\n
git add<\/strong> no solo sirve para archivos reci\u00e9n creados. Tambi\u00e9n funciona con archivos ya existentes que han cambiado, e incluso con archivos borrados, si lo combinas con la opci\u00f3n adecuada.<\/p>\n
Archivos nuevos<\/h3>\n
Cuando creas un archivo que Git todav\u00eda no conoce, aparecer\u00e1 como no rastreado. Al ejecutar git add<\/strong>, pasa a formar parte del seguimiento del repositorio.<\/p>\n
git add nueva-funcionalidad.js\n<\/code><\/pre>\n
Archivos modificados<\/h3>\n
Si editas un archivo que ya est\u00e1 versionado, Git detecta las diferencias. Al a\u00f1adirlo otra vez, preparas la nueva versi\u00f3n para el siguiente commit.<\/p>\n
git add fragmento.html\n<\/code><\/pre>\n
Archivos eliminados<\/h3>\n
Si borras un archivo y quieres que esa eliminaci\u00f3n quede registrada, puedes usar:<\/p>\n
git add -A\n<\/code><\/pre>\n
Esto es \u00fatil cuando eliminas recursos que ya no forman parte del proyecto, como im\u00e1genes antiguas o componentes obsoletos. Si quieres ser m\u00e1s expl\u00edcito, tambi\u00e9n puedes usar herramientas como git status<\/strong> para comprobar que la eliminaci\u00f3n ha quedado preparada correctamente.<\/p>\n
A\u00f1adir solo partes concretas de un archivo<\/h2>\n
En proyectos reales, no siempre quieres meter todos los cambios de un archivo. A veces haces varias pruebas y solo una parte merece entrar en el commit. Para eso existe el modo interactivo.<\/p>\n
git add -p\n<\/code><\/pre>\n
Con esta opci\u00f3n, Git te muestra fragmentos de cambios y te permite decidir cu\u00e1les preparar. Es una t\u00e9cnica muy \u00fatil para mantener commits limpios, coherentes y centrados en una sola tarea.<\/p>\n
Si est\u00e1s trabajando en una funcionalidad compleja o corrigiendo varios detalles a la vez, esta forma de a\u00f1adir cambios puede marcar una gran diferencia en la mantenibilidad del historial.<\/p>\n
Errores comunes al usar git add<\/h2>\n
Uno de los errores m\u00e1s frecuentes es usar git add .<\/strong> sin revisar el estado del proyecto. Eso puede hacer que incluyas archivos temporales, pruebas incompletas o cambios que no deber\u00edan publicarse todav\u00eda.<\/p>\n
Otro fallo habitual es pensar que el archivo ya est\u00e1 guardado en el repositorio despu\u00e9s de ejecutarlo. Recuerda: hasta que no hagas git commit<\/strong>, el cambio solo est\u00e1 preparado, no confirmado.<\/p>\n
Tambi\u00e9n conviene vigilar los archivos generados autom\u00e1ticamente, como compilaciones, cach\u00e9s o dependencias locales. La pr\u00e1ctica recomendada es apoyarse en un buen .gitignore<\/strong> para evitar a\u00f1adirlos por accidente.<\/p>\n
Una secuencia segura para trabajar<\/h3>\n
Una rutina sencilla y fiable ser\u00eda esta:<\/p>\n
git status           # revisar el estado actual\ngit add archivo.js   # preparar solo lo necesario\ngit status           # confirmar qu\u00e9 qued\u00f3 en staging\ngit commit -m \"Describe el cambio con claridad\"\n<\/code><\/pre>\n
Este flujo te ayuda a tomar decisiones m\u00e1s limpias y a mantener commits m\u00e1s f\u00e1ciles de entender, revisar y revertir si fuera necesario.<\/p>\n
buenas pr\u00e1cticas al a\u00f1adir archivos al repositorio<\/h2>\n
Usa git add<\/strong> con intenci\u00f3n, no como un gesto autom\u00e1tico. A\u00f1ade \u00fanicamente los archivos que forman parte del mismo cambio l\u00f3gico. Si una modificaci\u00f3n toca estilos, l\u00f3gica y documentaci\u00f3n, piensa si realmente debe ir todo junto o si conviene separarlo.<\/p>\n
Adem\u00e1s, escribe commits coherentes con lo que preparaste. Un buen staging facilita mensajes claros y evita historias confusas. Esta disciplina es especialmente valiosa cuando colaboras con otras personas o cuando vuelves a un proyecto despu\u00e9s de varias semanas.<\/p>\n
Si vienes de configurar tu entorno con git config<\/a>, este es el momento de convertir la teor\u00eda en h\u00e1bito: revisar, preparar y confirmar con criterio.<\/p>\n
Conclusi\u00f3n<\/h2>\n
git add<\/strong> es mucho m\u00e1s que un comando previo al commit. Es la herramienta que te permite elegir exactamente qu\u00e9 cambios formar\u00e1n parte de la siguiente versi\u00f3n del proyecto. Aprender a usarlo bien mejora tu control, tu productividad y la calidad general de tu historial en Git.<\/p>\n
Si integras el h\u00e1bito de revisar con git status<\/strong>, preparar cambios con precisi\u00f3n y confirmar solo lo necesario, estar\u00e1s construyendo una base s\u00f3lida para trabajar con ramas, merges y flujos colaborativos m\u00e1s avanzados.<\/p>\n
Fuentes y lecturas recomendadas<\/h3>\n