Los cuatro comandos
Este es el capítulo más corto del libro y el que más vas a repetir. Cuatro comandos, en este orden, y ya tienes un repositorio funcionando.
Primero la carpeta, y entrar en ella. Es en serio lo de entrar: si te saltas
el cd, Git convierte en repositorio la carpeta donde estés
parada, y ahí empiezan los problemas de la trampa del capítulo
1.
mkdir ventas-miss-yera cd ventas-miss-yera git init
Initialized empty Git repository in /home/miss-yera/ventas-miss-yera/.git/
Mira dónde dice que lo creó: dentro de la carpeta, en un sitio llamado
.git. Ese punto delante significa oculto, y por eso no lo ves en el
explorador de archivos.
ls -a
. .. .git
Esa carpeta .git es el repositorio. Toda la
historia vive ahí dentro. Si la borras, la carpeta vuelve a ser una carpeta
normal y pierdes la memoria pero no los archivos.
El error de empezar al revés
Antes de crear nada, intento señalar un archivo que todavía no existe. Este error lo vas a ver mucho al principio:
git add ventas.csv
fatal: pathspec 'ventas.csv' did not match any files
Did not match any files: no encontró ningún archivo con ese nombre.
Casi siempre es un nombre mal escrito o que estás en otra carpeta. Se resuelve
con un ls, mirando qué hay de verdad ahí dentro.
El estado, que es tu tablero
Creo el archivo de ventas y pregunto cómo está la cosa:
printf 'ciudad,monto,canal\nLima,1200,bodega\n' > ventas.csv
git status
On branch main No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) ventas.csv nothing added to commit but untracked files present (use "git add" to track)
Léelo despacio porque este mensaje te va a acompañar toda la vida:
On branch main, estás en la rama principal. No commits yet, todavía no has guardado ningún momento. Untracked files, hay archivos que Git ve pero no está siguiendo.
Y de yapa te dice qué hacer: use git add. Git es de los pocos programas que te propone el siguiente comando en el propio mensaje. Léelos, no los saltes.
Señalar y guardar, que son dos cosas
git add ventas.csv git status
On branch main No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: ventas.csv
Cambió una palabra y cambió todo. Ahora dice Changes to be committed, cambios listos para guardarse, y el archivo aparece como new file.
Ese sitio intermedio donde está ahora el archivo se llama el área de preparación, y es lo que hace distinto a Git. En otros sistemas guardas todo lo que cambió, sí o sí. Aquí eliges: tocaste ocho archivos en la mañana pero solo tres son de la misma tarea, señalas esos tres y haces un commit limpio.
Ahora sí, guardo el momento:
git commit -m "Primeras ventas de Lima por bodega"
[main (root-commit) 2e3153e] Primeras ventas de Lima por bodega 1 file changed, 2 insertions(+) create mode 100644 ventas.csv
Y el estado vuelve a estar tranquilo:
git status
On branch main nothing to commit, working tree clean
Nothing to commit, working tree clean. Todo lo que hay en la carpeta está guardado en la historia. Cuando algo te asuste, este es el mensaje que quieres ver 🧘
Tu hash no va a ser el mío
Mira el commit completo:
git log
commit 2e3153e3821f6e536d12b36c66688a456910b156
Author: Miss Yera <hola@missyera.com>
Date: Thu Jan 15 09:00:00 2026 -0500
Primeras ventas de Lima por bodega
Esos cuarenta caracteres son el nombre del momento. Salen de mezclar lo que guardaste, quién lo firmó y a qué hora, así que si tú haces los mismos pasos te va a salir otro número, porque tu nombre y tu reloj son otros.
Lo digo temprano porque es la duda que más veo: "me salió distinto al del libro, ¿hice algo mal?". No. Lo que tiene que coincidir es la forma, no el número.
Y como cuarenta caracteres no se leen, casi siempre vas a usar la versión corta, que toma los siete primeros:
git log --oneline
2e3153e Primeras ventas de Lima por bodega
Con siete basta para que no haya dos iguales en un proyecto normal, y ese es el que copias cuando alguien te pregunta en qué commit está algo.
La trampa
Terminas de configurar la conexión a la base de datos de la tienda, guardas las claves en un archivo .env al lado de tu código y haces tu primer commit del día como siempre.
$ git add . $ git commit -m "Conexion a la base de ventas" $ git push [main 8f2a91c] Conexion a la base de ventas 4 files changed, 62 insertions(+)
Qué está mal
Ese punto se llevó el .env con tus claves 🔑 y ahora están en internet.git add . significa "agrega todo lo que haya cambiado", y todo incluye lo que no querías. El commit no avisa: dice cuatro archivos y tú creías que eran tres.
Lo peor no es eso. Lo peor es que borrar el commit no arregla nada: la clave ya se publicó, ya la copiaron los robots que rastrean GitHub buscando exactamente esto, y lo único que sirve es entrar al proveedor y rotarla. El archivo se quita después, con calma.
La costumbre que evita esto es mirar antes de guardar: git status primero, y nombrar los archivos uno por uno en el git add.
Comprueba que se entendió
Comprueba que lo tienes
Cambiaste cinco archivos pero solo tres son de la misma tarea. ¿Qué haces?
git add .y un commit con todogit addcon los tres archivos y un commit, y después los otros dos aparte- Guardar los cinco y arreglarlo después
- Borrar los dos que no van y volver a escribirlos luego
Ejercicios
1. Un segundo archivo, con los clientes
Crea un CSV con dos bodegas y míralo en el estado, sin guardarlo todavía.
printf 'bodega,ciudad\nMinimarket Sol,Lima\nBodega Rosita,Arequipa\n' > clientes.csv
git status --short
?? clientes.csv
El --short es la versión resumida del estado. Las dos
interrogaciones significan que Git no conoce ese archivo todavía.
2. Señálalo y mira cómo cambia la marca
Haz el add y vuelve a pedir el estado corto.
git add clientes.csv git status --short
A clientes.csv
La A es de added. Con la versión corta lees el estado de
un vistazo, y cuando tengas veinte archivos lo vas a agradecer.
3. Guárdalo con un mensaje que se entienda
Haz el commit. Regla del libro: el mensaje dice qué pasó, nunca dice "cambios" ni "update".
git commit -m "Se agregan las bodegas de Lima y Arequipa"
[main cad0faa] Se agregan las bodegas de Lima y Arequipa 1 file changed, 3 insertions(+) create mode 100644 clientes.csv
Un buen mensaje se lee como el titular de una noticia: qué pasó, en presente, sin adornos.
4. Dos archivos, un solo commit, a propósito
Toca los dos archivos y guárdalos juntos, porque esta vez sí son la misma tarea: agregar Cusco como ciudad nueva.
printf 'Cusco,760,minimarket\n' >> ventas.csv printf 'Bodega Inti,Cusco\n' >> clientes.csv git add ventas.csv clientes.csv git commit -m "Entra Cusco en ventas y en clientes"
[main 54d6b5d] Entra Cusco en ventas y en clientes 2 files changed, 2 insertions(+)
Dos archivos cambiados en el mismo momento porque cuentan la misma historia. Ese es el criterio: un commit, una idea 💡
5. Lee la historia en dos formatos
Pide el log corto y cuenta cuántos commits llevas.
git log --oneline git log --oneline | wc -l
54d6b5d Entra Cusco en ventas y en clientes cad0faa Se agregan las bodegas de Lima y Arequipa 2e3153e Primeras ventas de Lima por bodega 3
Tres momentos, cada uno con su frase. Y el wc -l cuenta las
líneas, que es un truco de terminal que sirve para todo.
6. Qué entró en el último commit
Pide el detalle del último momento, solo los nombres de los archivos que tocó.
git show --stat --oneline HEAD
54d6b5d Entra Cusco en ventas y en clientes clientes.csv | 1 + ventas.csv | 1 + 2 files changed, 2 insertions(+)
Los dos archivos que guardaste juntos, y cuántas líneas entraron en cada uno. Esto es lo primero que mira alguien que revisa tu trabajo.
7. El commit vacío
Intenta guardar un momento cuando no hay nada que guardar. Tiene que fallar, y el mensaje te va a resultar familiar.
git commit -m "Otro commit"
On branch main nothing to commit, working tree clean
Git no crea momentos vacíos. Si te sale esto y tú sí cambiaste algo, casi
siempre es que se te olvidó el git add 🔁
Lo que te llevas
Señalar y guardar son dos pasos porque tú decides qué historia cuenta cada commit.