Tutorial de Git: comandos básicos (add, commit, push, pull)

Cinco comandos bastan para el día a día: status, add, commit, push y pull. Este capítulo los repasa uno a uno y luego entra en lo que ningún tutorial debería saltarse: cómo dar marcha atrás cuando te equivocas.

Un requisito previo: tu identidad tiene que estar declarada o Git rechazará tu primer commit. Si aún no lo has hecho, vuelve al capítulo de instalación.

Las tres zonas de Git

Todo se vuelve más sencillo en cuanto entiendes que tus archivos están siempre en una de estas tres zonas.

• El directorio de trabajo: tus archivos tal y como los ves en el explorador.
• El índice, también llamado staging area: la lista de lo que entrará en el próximo commit. git add coloca ahí los cambios.
• El repositorio: el historial de commits, lo que alimenta git commit.

Esa zona intermedia despista al principio, pero es la que te permite registrar tres cambios de cinco y guardar los otros dos para un commit aparte.

git status, el comando que se teclea todo el rato

Te dice en qué punto estás, y sus mensajes contienen casi siempre el comando que toca escribir después. Acostúmbrate a lanzarlo antes y después de cada operación.

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.env
	app.js
	node_modules/

nothing added to commit but untracked files present (use "git add" to track)

La versión corta cabe en una línea por archivo y enseguida se convierte en un reflejo:

git status --short

?? .env
?? app.js
?? node_modules/

?? señala un archivo que Git aún no rastrea, A un archivo añadido al índice, M un archivo modificado.

.gitignore: lo que nunca debe llegar al repositorio

Antes incluso del primer git add, aparta todo lo que no pinta nada en un repositorio: las dependencias reinstalables, los archivos de configuración con secretos, los archivos que generan tu sistema o tu editor.

Crea un archivo .gitignore en la raíz del proyecto:

node_modules/
vendor/
.env
.env.local
dist/
build/
*.log
.DS_Store
.idea/
.vscode/

Vuelve a lanzar git status: los archivos ignorados han desaparecido de la lista.

?? .gitignore
?? app.js

El .gitignore, en cambio, sí se versiona: forma parte del proyecto y hay que compartirlo con el equipo.

Cuidado con una trampa: .gitignore no tiene ningún efecto sobre un archivo que ya se rastrea. Si has hecho commit de un .env antes de caer en la cuenta, hay que sacarlo explícitamente del índice:

git rm --cached .env
git commit -m "Retire le fichier .env du suivi"

La opción --cached es esencial: retira el archivo del índice sin borrarlo de tu disco.

Y da por comprometidos los secretos que contenía: siguen siendo legibles en el historial. Cámbialos.

git add: preparar el commit

git add app.js          # un archivo
git add src/            # una carpeta entera
git add .               # todo lo que ha cambiado bajo la carpeta actual
git add -p              # elegir trozo a trozo, de forma interactiva

Vale la pena probar git add -p pronto. Git te presenta cada bloque de cambios y te pregunta si lo quieres en el commit. Es la manera más sencilla de producir commits que cuentan una sola cosa.

git commit: registrar

git commit -m "Ajoute la page d'accueil"

[main (root-commit) fd4fdb7] Ajoute la page d accueil
 2 files changed, 3 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 app.js

Si no hay nada en el índice, Git no crea nada y te lo dice:

On branch main

Initial commit

nothing to commit (create/copy files and use "git add" to track)

Sobre los mensajes de commit solo merece la pena retener una regla: escribe lo que hace el commit, no lo que has tocado. «Corrige el cálculo del IVA en los pedidos fuera de la UE» vale más que «modif facture.php». Escribes para ti mismo dentro de seis meses.

El atajo -am combina add y commit, pero solo para los archivos que ya se rastrean:

git commit -am "Corrige le libellé du bouton"

Leer el historial

git log                                  # completo
git log --oneline                        # una línea por commit
git log --oneline --graph --decorate     # con la forma de las ramas
git log -p app.js                        # el historial de un solo archivo, con los diffs

* fd4fdb7 (HEAD -> main) Ajoute la page d accueil

HEAD designa el punto del historial en el que te encuentras. La flecha indica que HEAD sigue a la rama main.

Ver tus cambios antes de hacer commit

Dos comandos que se confunden a menudo y que miran dos zonas distintas.

git diff            # lo que ha cambiado pero aún no está en el índice
git diff --staged   # lo que está en el índice y saldrá en el próximo commit

diff --git a/app.js b/app.js
index e921523..ebde020 100644
--- a/app.js
+++ b/app.js
@@ -1 +1 @@
-console.log('hello');
+console.log('bonjour');

Después de un git add app.js, ese mismo cambio cambia de bando: git diff ya no devuelve nada y git diff --staged muestra el bloque. Es la mejor forma de visualizar el índice.

git push y git pull: intercambiar con el servidor

git push        # enviar los commits locales
git pull        # traer e integrar los de los demás

Estas dos formas cortas solo funcionan si la rama tiene un vínculo con el servidor, establecido por el -u del capítulo anterior. Para comprobar ese vínculo:

git branch -vv

* feature/panier bc2203a Page d accueil
  main           bc2203a [origin/main] Page d accueil

La rama main sigue a origin/main, la rama feature/panier no sigue nada por ahora.

Si alguien ha hecho push mientras tú trabajabas, tu push es rechazado. El procedimiento y la explicación completa están en el capítulo sobre las ramas.

Deshacer una metedura de pata

Es la parte que más buscan los principiantes y la que menos se les explica. El buen reflejo consiste en responder primero a una pregunta: ¿lo que quiero deshacer ya ha salido hacia el servidor?

El archivo está modificado y quiero volver al último commit

git restore app.js       # un archivo
git restore .            # todo el directorio de trabajo

Cuidado: este comando destruye tus cambios sin red. Nunca se guardaron en ninguna parte, Git no puede recuperarlos.

He hecho git add demasiado deprisa

git restore --staged app.js

El archivo sale del índice, tus cambios siguen intactos en el directorio de trabajo.

Estos dos comandos son el equivalente moderno de git checkout -- fichier y git reset HEAD fichier. git restore existe desde Git 2.23 y dice claramente lo que hace, mientras que checkout y reset hacen cada uno tres cosas distintas según las opciones.

El mensaje de mi último commit está mal

git commit --amend -m "Le bon message"

El mismo comando sirve para añadir un archivo olvidado: haz tu git add y vuelve a lanzar git commit --amend. Úsalo solo en un commit que todavía no hayas subido: --amend no modifica el commit, crea uno nuevo en su lugar y el identificador antiguo desaparece.

El commit ya está subido y quiero deshacerlo limpiamente

git revert HEAD

[main 0246de1] Revert "Ajoute un fichier par erreur"
 1 file changed, 1 deletion(-)
 delete mode 100644 bug.txt

git revert crea un nuevo commit que aplica lo contrario del anterior. El historial se alarga en lugar de reescribirse, que es justo lo que hace falta cuando otras personas ya se han traído tu trabajo. Es el único método sin peligro en una rama compartida.

El commit no está subido y quiero eliminarlo

git reset --soft HEAD~1   # deshace el commit y lo deja todo en el índice
git reset --mixed HEAD~1  # deshace el commit y conserva los archivos modificados (comportamiento por defecto)
git reset --hard HEAD~1   # deshace el commit y borra los cambios

--soft es el más útil: te devuelve tus cambios listos para volver a registrarlos de otra forma. --hard es el único que destruye trabajo, y no avisa. No lo teclees si no estás seguro.

He hecho un reset –hard de más

No está todo perdido. Git conserva durante varias semanas el rastro de todos los estados por los que ha pasado HEAD:

git reflog

8207e54 HEAD@{0}: reset: moving to HEAD~2
f3951da HEAD@{1}: commit: Version 3
8ac671c HEAD@{2}: commit: Version 2
8207e54 HEAD@{3}: commit (initial): Version 1

Los dos commits borrados siguen ahí. Localiza la línea que corresponde al estado que quieres, apunta su identificador y vuelve a él:

git reset --hard f3951da

El reflog, en cambio, solo rescata lo que se había registrado en un commit. Los cambios que nunca se guardaron están definitivamente perdidos, un argumento más para hacer commits a menudo.

El resumen

Ya sabes trabajar solo. El capítulo siguiente añade a los demás: ramas, fusiones y conflictos. El último capítulo tratará después la organización de esas ramas a escala de equipo.