Capítulo 23 de 33 9 secciones 7 min

Revisar el trabajo de otra persona

Cómo se lee un cambio, qué se comenta y por qué hay que bajarlo

<strong>Se lee el diff, se baja la rama y se ejecuta.</strong> Leer te dice si el cambio es razonable; ejecutarlo te dice si funciona, y son dos cosas distintas. Bajar una rama ajena son dos comandos: <code>git fetch</code> y <code>git switch</code>. Y al comentar, la regla que más sirve es separar lo que bloquea de lo que es gusto personal, porque si todo suena igual de grave nadie sabe qué arreglar primero.

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 diffSolo bajándolo y ejecutando
Si el cambio hace lo que dice el títuloSi 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 entiendenSi la salida es la que se esperaba
Si falta documentar algoCuá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_total a 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.

¿Tienes alguna duda o consulta?