El primer repositorio

“¿Cuál es la buena? ¿capitulo-final.md, capitulo-final-2.md o capitulo-final-DEFINITIVO.md?” Sin control de versiones, cada cambio importante acaba en una copia con otro nombre, y nadie sabe quién cambió qué ni cuándo. Git resuelve eso: guarda la historia de una carpeta, versión a versión, con quién hizo cada cambio, cuándo y por qué. Es lo que usan casi todos los equipos que hacen software… y cualquiera que trabaje con archivos de texto.

En este tema trabajas con los textos de Ediciones Brújula, una editorial pequeña que guarda en Git sus libros. Cada sección tiene un ejercicio con una terminal: el servidor es el Ubuntu de siempre (lo del track de Linux sigue valiendo) y tiene Git instalado.

El repositorio: git init

Un repositorio es una carpeta cuya historia lleva Git. Se crea con git init dentro de ella:

tecnico@srv-pruebas:~/libro$ git init
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. …
Initialized empty Git repository in /home/tecnico/libro/.git/

Todo lo de Git va en una carpeta oculta, .git: la historia, la configuración del repositorio y lo preparado para el próximo commit. Los archivos de siempre se quedan donde estaban. (Las hint: son consejos: la rama principal se llama master si no se dice otra cosa; las ramas llegan en el tema 3.)

git status es la orden que más vas a usar: dice cómo está todo.

tecnico@srv-pruebas:~/libro$ git status
On branch master

No commits yet

Untracked files:
(use "git add <file>..." to include in what will be committed)
capitulo-1.md
portada.txt

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

Untracked quiere decir “sin seguir”: Git ve los archivos, pero aún no los guarda.

Quién firma: git config

Cada commit lleva el nombre y el correo de quien lo hace. Git no se los inventa: si no se los has dicho, no te deja guardar.

tecnico@srv-pruebas:~/libro$ git commit -m "Primera versión"
Author identity unknown

*** Please tell me who you are.

Run

git config --global user.email "[email protected]"
git config --global user.name "Your Name"
…

Se dicen una vez por máquina, con --global (valen para todos tus repositorios; se guardan en ~/.gitconfig):

tecnico@srv-pruebas:~/libro$ git config --global user.name "Ana Técnica"

tecnico@srv-pruebas:~/libro$ git config --global user.email [email protected]

git config user.name dice el que hay, y git config --list, toda la configuración. Sin --global, vale solo para el repositorio en el que estás (útil si en uno firmas con el correo del trabajo y en otro con el tuyo).

Preparar y guardar: git add y git commit

Guardar en Git son dos pasos, y entre medias está la clave de todo:

1. git add archivo prepara un cambio: lo apunta para el próximo commit. Lo preparado vive en el índice (en inglés, staging area).
2. git commit -m "mensaje" guarda en la historia todo lo preparado, y solo eso.

Así un archivo puede estar en tres sitios: en tu carpeta (cambiado), en el índice (preparado) y en la historia (guardado). git status te dice dónde está cada cosa:

tecnico@srv-pruebas:~/libro$ git status -s
A  capitulo-1.md
?? portada.txt

En la forma corta (-s), la primera columna es lo preparado y la segunda lo cambiado sin preparar: A es nuevo, M modificado, D borrado y ?? sin seguir. Tras guardar:

tecnico@srv-pruebas:~/libro$ git commit -m "Primera versión"
[master (root-commit) 656c90a] Primera versión
1 file changed, 3 insertions(+)
create mode 100644 capitulo-1.md

656c90a es el principio del hash del commit, su nombre único (40 cifras y letras, sacadas de lo que guarda). Lo preparado desaparece de git status: ya está guardado.

El historial: git log

git log enseña los commits, del más nuevo al más viejo: su hash entero, quién, cuándo y el mensaje. (HEAD -> master) marca dónde estás.

tecnico@srv-pruebas:~/libro$ git log
commit db58b68b90451a54aaa21370eb6c7a733b0371b8 (HEAD -> master)
Author: Ana Técnica <[email protected]>
Date:   Mon Nov 2 09:16:00 2026 +0000

  Sigue el capítulo 1

commit aa8c72cfd29da80b23c2c0d34c798bd44d93bf9d
Author: Ana Técnica <[email protected]>
Date:   Mon Nov 2 09:12:00 2026 +0000

  La portada
…

Algunas formas de pedirlo:

tecnico@srv-pruebas:~/libro$ git log --format='%h %an %ar: %s'
db58b68 Ana Técnica 5 minutes ago: Sigue el capítulo 1
aa8c72c Ana Técnica 9 minutes ago: La portada
656c90a Ana Técnica 11 minutes ago: Primera versión

Renombrar y borrar: git mv y git rm

Si renombras o borras un archivo con mv o rm, Git solo ve que uno ha desaparecido (y que hay otro sin seguir): luego hay que prepararlo. git mv y git rm hacen las dos cosas a la vez: cambian el archivo y preparan el cambio.

tecnico@srv-pruebas:~/libro$ git mv portada.txt cubierta.txt

tecnico@srv-pruebas:~/libro$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
renamed:    portada.txt -> cubierta.txt

Git lo ve como un renombrado (no un borrado y un archivo nuevo): la historia del archivo sigue con él. git rm archivo lo borra de la carpeta y del próximo commit; si tiene cambios sin guardar, se niega (con -f lo borra igual).

Un buen mensaje (y el editor)

El mensaje es lo que lee quien venga detrás (tú, dentro de seis meses). La costumbre: un título corto (menos de unos 50 caracteres) que diga qué hace el commit, una línea en blanco y, si hace falta, una explicación de por qué.

Para escribirlo con calma, git commit sin -m abre un editor (en Ubuntu, nano) con una plantilla: las líneas que empiezan por # son comentarios y no se guardan. Escribes arriba, guardas con Ctrl+O y sales con Ctrl+X; al salir, Git hace el commit con lo escrito. Si sales sin escribir nada, no hay commit: “Aborting commit due to empty commit message.” Con dos -m se consigue lo mismo sin editor: el primero es el título y el segundo, la explicación.

Resumen