git add, commit y push: el flujo básico de Git explicado

Copiaste git add ., git commit -m "..." y git push de algún tutorial y desde entonces los tecleas como un conjuro. Tres líneas seguidas, siempre las mismas, sin saber muy bien qué hace cada una. Si funciona, funciona. Pero en algún momento aparece el nothing to commit o un Everything up-to-date que no esperabas, y ahí el conjuro deja de servir. La pregunta de verdad es: ¿por qué tres comandos para guardar mi trabajo y no uno? Este post convierte esas tres líneas en un modelo mental que puedes razonar.

Para seguirlo necesitas tener Git instalado y un repositorio ya iniciado con git init o clonado con git clone. Si todavía no estás ahí, empieza por la guía de primeros pasos con Git y vuelve luego.

¿Por qué Git necesita tres pasos y no uno?

Git usa tres comandos porque tu trabajo pasa por cuatro sitios distintos antes de llegar a un servidor, y cada comando lo empuja de un sitio al siguiente. No es burocracia. Es lo que te da control sobre qué guardas y cuándo.

Piensa en cómo enviarías un paquete por correo. Primero tienes cosas sueltas encima de la mesa. Eliges cuáles metes en la caja y cuáles dejas fuera. Cierras la caja, le pegas una etiqueta con tu letra y la dejas lista en el recibidor de tu casa. Y solo cuando la llevas a la oficina de correos sale de tu casa y viaja a su destino. Git funciona igual, y esos cuatro momentos tienen nombre:

• Working directory (el directorio de trabajo): la carpeta de tu proyecto tal y como la ves en tu editor. Aquí están tus archivos con los cambios recién hechos, sueltos encima de la mesa.
• Staging area (la zona de preparación, también llamada índice): la caja donde vas metiendo los cambios que quieres guardar en el próximo commit. Es una sala de espera. Puedes meter y sacar cosas antes de cerrar.
• Repositorio local: el historial de tu proyecto guardado dentro de la carpeta oculta .git, en tu máquina. Cada commit es una foto guardada aquí. Todavía no ha salido de tu ordenador.
• Repositorio remoto: la copia que vive en un servidor como GitHub o GitLab, la que ven tus compañeros y desde la que se despliega.

Cada comando mueve tu cambio exactamente un salto entre estas áreas. Empecemos por el que mete las cosas en la caja.

git add: llevar tus cambios al staging area

git add copia el estado actual de los archivos que le indiques al staging area, la zona donde preparas el próximo commit. Es el paso donde eliges: de todo lo que has tocado, esto es lo que quiero guardar ahora.

Aquí es donde git status se convierte en tu brújula. Antes de añadir nada, mira qué tienes:

# Ver el estado de tu working directory y tu staging area
$ git status

# Cambios que Git NO ha metido todavía en la caja:
#   modificado: login.js       (archivo ya conocido, editado)
#   sin seguimiento: notas.txt  (archivo nuevo que Git nunca ha visto)

Eso es una lectura traducida de lo que Git te dice, no la salida literal: en una instalación por defecto aparece en inglés (Changes not staged for commit:, Untracked files:). Si comparas con tu terminal y lo ves en otro idioma, no es que algo falle.

Para meter un archivo concreto en la caja, lo nombras. Para meter todos los cambios de la carpeta de golpe, usas el punto:

$ git add login.js   # mete solo login.js en el staging area
$ git add .          # mete TODOS los cambios de la carpeta actual

Dos cosas que git add no hace, y que confunden al principio. No guarda nada de forma permanente: solo prepara la caja para el próximo commit, y puedes volver a ejecutarlo tantas veces como quieras. Y solo captura el estado del archivo en el momento en que lo ejecutas. Si editas login.js otra vez después de hacer git add login.js, esa última edición se queda fuera hasta que vuelvas a añadirla.

Esa sala de espera es más potente de lo que parece, y merece su propia explicación cuando quieras exprimirla. La tienes en el staging area de Git al detalle. Y si la salida de git status te resulta un jeroglífico, aquí te enseño a leerla línea a línea.

git commit: fotografiar el staging area

git commit toma una instantánea de lo que hay en el staging area y la guarda de forma permanente en tu repositorio local, con un identificador único y un mensaje que escribes tú. Fija la caja: a partir de ahí ese conjunto de cambios queda registrado en el historial y siempre podrás volver a él.

Solo entra en el commit lo que estaba en el staging area. Lo que dejaste fuera con git add no viaja en esta foto.

# Fotografía lo que hay en el staging area y le pone un mensaje
$ git commit -m "Añade validación al formulario de login"

[main a3f9c2e] Añade validación al formulario de login
 1 file changed, 8 insertions(+)

Ese a3f9c2e es el hash, el identificador de tu commit. Es un código hexadecimal que Git calcula a partir de la instantánea, el commit anterior, el autor y el mensaje: cualquier diferencia en esos datos produce un hash distinto. Sirve para referirte a ese commit exacto entre todos los demás. El mensaje es para los humanos: tu yo del futuro y tus compañeros lo leerán para entender qué cambió sin abrir el código.

Aquí está el detalle que casi nadie te cuenta al principio: ese commit vive solo en tu máquina. Está guardado, sí, pero dentro de la carpeta .git de tu ordenador. Nadie más lo ve todavía. Para eso falta el último salto.

git push: enviar tus commits al remoto

git push es el único de los tres comandos que habla con el servidor: envía los commits que tienes en tu repositorio local al repositorio remoto y sube los datos que aún no están allí ^[1]. Add y commit trabajan siempre dentro de tu máquina. Push es el que cruza la puerta.

# Sube tus commits locales de la rama main al remoto llamado origin
$ git push origin main

origin es el nombre por defecto del repositorio remoto, normalmente el que clonaste al principio. main es la rama que estás enviando. Así que git push origin main se lee como “sube mi rama main al remoto origin”. No tienes que pelearte con esos dos nombres cada día: cuando la rama ya está enlazada con su remoto, un git push a secas basta.

Hasta que no ejecutas este comando, tus compañeros no ven nada de lo que has hecho, por muchos commits que tengas. El remoto no adivina lo que hay en tu máquina. Solo sabe lo que le has enviado.

Qué mueve cada comando

Tres comandos, tres saltos. Esta es la tabla que conviene tener en la cabeza:

Comando	De dónde	A dónde	¿Toca el remoto?
git add	Working directory	Staging area	No
git commit	Staging area	Repositorio local	No
git push	Repositorio local	Repositorio remoto (GitHub)	Sí, es el único

Fíjate en la última columna. Los dos primeros comandos no salen nunca de tu ordenador; el tercero es el que publica.

El bucle de un día normal

En un día de trabajo real no ejecutas los tres comandos una sola vez. Repites el ciclo cada vez que terminas una unidad de trabajo que tiene sentido guardar. El patrón es siempre el mismo: editas, miras el estado, añades, commiteas, y de vez en cuando subes.

# 1. Editas archivos en tu editor y los guardas
# 2. Miras qué ha cambiado
$ git status

# 3. Metes en la caja lo que quieres guardar
$ git add login.js

# 4. Fotografías el cambio con un mensaje claro
$ git commit -m "Corrige el mensaje de error del login"

Puedes repetir los pasos 1 a 4 varias veces a lo largo de la mañana, acumulando commits en tu repositorio local. Cuando quieras compartir tu avance, subes todo de una:

# Sube todos los commits que hayas acumulado
$ git push

Editar, status, add, commit, y push cuando toque. Ese es todo el bucle. La única pieza que decides tú es cada cuánto commiteas (mejor commits pequeños y frecuentes) y cada cuánto haces push.

Aquí lo puedes practicar sin miedo a romper nada, moviendo un cambio a través de las cuatro áreas:

Cargando ejercicio...

Errores frecuentes cuando empiezas

Casi todos los tropiezos del principio salen de olvidar por qué área va pasando tu cambio. Estos son los que verás una y otra vez.

Guardar en el editor no es hacer un commit

Le das a Ctrl+S, ves el punto del archivo modificado desaparecer en tu editor, y das por hecho que ya está guardado en Git. No lo está. Guardar en el editor solo escribe el archivo en tu working directory. Para Git ese cambio sigue suelto encima de la mesa hasta que haces add y commit. Son dos “guardados” distintos que ocurren en sitios distintos.

Hacer commit esperando que suba al remoto

Haces tu git commit, ves el mensaje con el hash, cierras el portátil, y al día siguiente tu compañero te dice que no ve tus cambios. Normal: git commit guarda en local. Sin git push, tu trabajo no ha salido de tu ordenador. El commit existe, pero solo para ti.

git commit -am con un archivo nuevo

El atajo git commit -a -m "..." (o -am) es cómodo porque hace add y commit en un solo paso, pero tiene una trampa que te morderá tarde o temprano. La opción -a solo mete en el commit los archivos que Git ya conocía y que has modificado o borrado. Un archivo nuevo que Git nunca ha visto no entra ^[2].

# Creas un archivo NUEVO y usas el atajo
$ git commit -am "Añade la página de contacto"
# contacto.html se queda FUERA del commit: Git no lo trackeaba todavía

La solución es un git add contacto.html explícito la primera vez, para que Git empiece a seguir ese archivo. A partir de ahí, -am ya lo incluirá en las siguientes.

git push sin nada que subir

Ejecutas git push y Git te contesta Everything up-to-date. Ese mensaje no es un fallo. Significa que no tienes ningún commit local pendiente de enviar. Casi siempre significa que se te olvidó el commit, o que guardaste en el editor pero nunca llegaste a add y commit. Comprueba con git status y git log antes de asumir que Git ha fallado.

nothing to commit

Haces git commit y aparece nothing to commit, working tree clean. Traducción: no hay nada en el staging area que fotografiar. O no has tocado ningún archivo, o los tocaste pero no hiciste git add. Recuerda el orden: sin add que llene la caja, commit no tiene nada que guardar.

Checklist para no perderte

• Sé que guardar el archivo en el editor no crea un commit
• Uso git status antes de cada commit para ver qué va a entrar
• Entiendo que git add selecciona los cambios y que sin él git commit no los incluye
• Tengo claro que git commit crea la instantánea, pero solo en mi máquina
• Sé que git push es el paso que sube los commits al remoto
• Recuerdo que git commit -a no incluye archivos nuevos sin trackear

Si quieres interiorizar este bucle con las manos en vez de solo leerlo, lo trabajamos paso a paso, con ejercicios interactivos, en el curso de Git de cero a profesional.

Fuentes

1. Documentación oficial de Git, git-push. Respalda que push actualiza referencias en el repositorio remoto y envía los datos que aún no están allí.
2. Documentación oficial de Git, git-commit. Describe la opción -a: añade automáticamente los archivos modificados y borrados ya trackeados, pero no los archivos nuevos.

Preguntas Frecuentes

¿Por qué git add, commit y push son tres pasos y no uno solo?

Porque cada comando actúa sobre un área distinta del recorrido de un cambio. git add lleva los cambios del working directory al staging area, git commit los guarda como una instantánea permanente en tu repositorio local, y git push los envía al repositorio remoto. Separarlos te da control: eliges qué guardas, cuándo lo fijas en tu historial y cuándo lo compartes con los demás.

¿git add . añade todo, incluso lo que no quiero subir?

Sí, git add . mete en el staging area todos los cambios de la carpeta actual: archivos nuevos, modificados y borrados. Por eso conviene mirar antes con git status y, si solo quieres guardar parte, añadir los archivos por su nombre en lugar de usar el punto. Para dejar fuera archivos de forma permanente (como claves o dependencias), existe el fichero .gitignore.

¿Puedo saltarme el staging area con git commit -a?

En parte. git commit -a hace el add y el commit en un solo paso, pero solo para archivos que Git ya trackeaba y que has modificado o borrado. Un archivo nuevo sin trackear no entra: la primera vez necesitas un git add explícito para que Git empiece a seguirlo.

¿Qué significa origin main en git push origin main?

origin es el nombre del repositorio remoto (normalmente el que clonaste) y main es la rama que estás enviando. Juntos significan “sube mi rama main al remoto origin”. Cuando tu rama local ya está enlazada con la remota, puedes escribir solo git push y Git sabe a dónde va.

¿git commit sube mi código a GitHub?

No. git commit guarda una instantánea en tu repositorio local, dentro de la carpeta .git de tu máquina. Nadie más la ve. El comando que sube tu código a GitHub es git push, el único de los tres que habla con el servidor.

Un concepto nuevo cada semana

Suscribirme