Revisar el trabajo de otra persona es la habilidad que más rápido te hace útil en un equipo, y casi nadie la enseña. Se aprende mirando cómo lo hacen otros, que es una forma elegante de decir que se aprende mal 🙃
Lo que una revisión sí puede ver
Y lo que no. Esta distinción es todo el capítulo:
| Leyendo el diff | Solo bajándolo y ejecutando |
|---|---|
| Si el cambio hace lo que dice el título | Si funciona con los datos reales |
| Si entró algo que no debía (una clave, un archivo suelto) | Si rompió otra cosa que ya andaba |
| Si los nombres se entienden | Si la salida es la que se esperaba |
| Si falta documentar algo | Cuánto tarda |
Primero, leer
Montamos un proyecto donde alguien propone un cambio en una rama:
mkdir proyecto cd proyecto git init -q printf 'ciudad,monto\nLima,1200\nArequipa,890\n' > ventas.csv printf '# Reporte de ventas\n' > README.md git add . git commit -q -m "Primera version del reporte de ventas" git switch -q -c agrega-canales printf 'canal,monto\nBodegas,4200\nHoreca,3100\n' > canales.csv printf 'Cusco,760\n' >> ventas.csv git add . git commit -q -m "Se agrega el reporte por canal y la ciudad de Cusco" git switch -q main git log --oneline --all
5de90d9 Se agrega el reporte por canal y la ciudad de Cusco 3d1883c Primera version del reporte de ventas
Lo primero que miro nunca es el código: es el tamaño.
git diff --stat main..agrega-canales
canales.csv | 3 +++ ventas.csv | 1 + 2 files changed, 4 insertions(+)
Dos archivos y pocas líneas se revisa bien. Cuarenta archivos y mil líneas no se revisa, se aprueba por cansancio, y esa es la principal causa de revisiones inútiles. Cuando veas algo así, lo que corresponde es pedir que se parta en varias propuestas 🔪
Después, el contenido
git diff main..agrega-canales
diff --git a/canales.csv b/canales.csv new file mode 100644 index 0000000..69306f5 --- /dev/null +++ b/canales.csv @@ -0,0 +1,3 @@ +canal,monto +Bodegas,4200 +Horeca,3100 diff --git a/ventas.csv b/ventas.csv index 0c80877..7a40551 100644 --- a/ventas.csv +++ b/ventas.csv @@ -1,3 +1,4 @@ ciudad,monto Lima,1200 Arequipa,890 +Cusco,760
Las líneas con + entran y las de - salen, igual
que en 6. Aquí ya se puede opinar con fundamento.
Y lo que casi nadie hace: bajarla
En un pull request de GitHub la rama ya está en tu remoto, así que son dos comandos:
git switch -q agrega-canales
ls
cat canales.csv
git log --oneline -1
README.md canales.csv ventas.csv canal,monto Bodegas,4200 Horeca,3100 5de90d9 Se agrega el reporte por canal y la ciudad de Cusco
Ahora tienes los archivos de la propuesta en tu carpeta y puedes ejecutar lo
que haga falta. Cuando terminas, vuelves a lo tuyo con
git switch main y no queda rastro 🔙
Qué comentar y cómo
La regla que más me ha servido: separa lo que bloquea de lo que es gusto. Si todo suena igual de grave, quien recibe la revisión no sabe por dónde empezar y se desanima.
- Bloquea: "esto rompe el reporte cuando el CSV viene vacío".
- Sugerencia: "yo llamaría
monto_totala esa columna, pero como está funciona". - Pregunta: "¿por qué se filtra Lima aquí y no antes?".
Y se comenta el código, no a la persona. "Esta función no maneja el caso de la bodega sin ventas" y no "no pensaste en el caso de la bodega sin ventas" 🙂
Aceptar la propuesta
git switch -q main
git merge -q --no-ff -m "Se acepta el reporte por canal" agrega-canales
git log --oneline
ls
696104b Se acepta el reporte por canal 3d1883c Primera version del reporte de ventas 5de90d9 Se agrega el reporte por canal y la ciudad de Cusco README.md canales.csv ventas.csv
Ese --no-ff obliga a dejar un commit de fusión aunque no hiciera
falta, y eso deja escrito en la historia que hubo una propuesta y que se
aceptó. En equipos es lo que quieres 📌
La trampa
Te toca revisar el pull request de un compañero. Lees el diff en GitHub, se ve bien, apruebas.
$ git log --oneline -1 9f3c2a1 Se acepta el reporte por canal # tres dias despues $ python3 reporte.py canales.csv KeyError: 'monto'
Qué está mal
El diff se veía perfecto porque el diff no ejecuta nada ✅❌
Leer el cambio te dice si el código es razonable. No te dice si funciona con los datos de verdad, ni si rompió otra cosa que ya andaba.
Para lo que importa hay que bajarlo: git fetch de la rama, cambiarte a ella y correrlo. Son dos comandos y es la diferencia entre una revisión de forma y una de fondo.
Yo tengo una regla simple: si el cambio toca datos o cálculos, se baja y se ejecuta. Si toca solo texto, se lee y ya.
Comprueba que se entendió
Comprueba que lo tienes
Te toca revisar un pull request de 40 archivos y 1200 líneas. ¿Qué haces?
- Lo leo entero con calma, aunque me tome la tarde
- Pido que se parta en propuestas más chicas
- Lo apruebo, si tiene tantos archivos seguro está pensado
- Reviso solo los archivos que conozco
Ejercicios
1. Monta una propuesta para revisar
Un proyecto con una rama que agrega el catálogo de clientes.
cd .. mkdir revision cd revision git init -q printf 'ciudad,monto\nLima,1200\n' > ventas.csv git add ventas.csv git commit -q -m "Primeras ventas de Lima" git switch -q -c agrega-clientes printf 'cliente,ciudad\nBodega Inti,Cusco\n' > clientes.csv git add clientes.csv git commit -q -m "Se agrega el catalogo de clientes" git switch -q main git log --oneline --all
3b61817 Se agrega el catalogo de clientes 54da6e2 Primeras ventas de Lima
Dos commits, uno en cada rama.
2. Mira el tamaño antes que nada
Cuántos archivos y cuántas líneas cambian.
git diff --stat main..agrega-clientes
clientes.csv | 2 ++ 1 file changed, 2 insertions(+)
Un archivo y dos líneas. Esto se revisa en un minuto ✅
3. Lee el cambio
El contenido exacto de la propuesta.
git diff main..agrega-clientes
diff --git a/clientes.csv b/clientes.csv new file mode 100644 index 0000000..5b6487f --- /dev/null +++ b/clientes.csv @@ -0,0 +1,2 @@ +cliente,ciudad +Bodega Inti,Cusco
Todo son líneas con +, porque el archivo es nuevo.
4. Comprueba que no entró nada de más
La revisión que hago siempre: buscar claves en lo que entra.
git diff main..agrega-clientes | grep "^+" | grep -i "key\|password\|secret" || echo "limpio"
limpio
Limpio. Si eso devuelve algo, la revisión se detiene ahí 🔑
5. Bájala y ejecútala
Cámbiate a la rama para tener los archivos delante.
git switch -q agrega-clientes ls cat clientes.csv git switch -q main ls
clientes.csv ventas.csv cliente,ciudad Bodega Inti,Cusco ventas.csv
Entras, miras, sales. Tu main quedó igual que estaba.
6. Acepta la propuesta dejando rastro
Fusiona con --no-ff para que quede escrito
que hubo una propuesta.
git merge -q --no-ff -m "Se acepta el catalogo de clientes" agrega-clientes
git log --oneline
ls
27e0c94 Se acepta el catalogo de clientes 54da6e2 Primeras ventas de Lima 3b61817 Se agrega el catalogo de clientes clientes.csv ventas.csv
Tres commits: los dos originales y el de la fusión 📌
7. Intenta revisar una rama que no existe
Pide el diff contra un nombre mal escrito, que es lo que pasa cuando copias el nombre de la rama con un dedazo.
git diff main..agrega-cliente
fatal: ambiguous argument 'main..agrega-cliente': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'
Git no adivina nombres parecidos. Te dice que ese no existe y no muestra nada 🛑
Lo que te llevas
Leer dice si es razonable; ejecutar dice si funciona. Y separa lo que bloquea de lo que es gusto.