Revisá un pull request localmente con un recorrido guiado.

Un PR puede tocar muchos archivos sin explicar por dónde empezar. Un walkthrough agrega un orden de lectura, un motivo por entrada y las partes que merecen atención.

git-review-workflow sigue ese orden mientras el PR completo sigue disponible como cambios staged en tu working tree. Podés inspeccionar la implementación y dejar observaciones sin editar código. Corré tests o hacé correcciones cuando te resulte útil; al terminar se extraen las correcciones que hayas hecho a otra rama.

Cuándo alcanza con un checkout

Si solo necesitás ejecutar un PR de GitHub, gh pr checkout de GitHub CLI hace el checkout:

gh pr checkout 123

Después podés inspeccionar el proyecto y correr sus tests. El flujo de esta guía agrega un recorrido de lectura, una vista staged del PR completo y la extracción de las correcciones que hagas durante la revisión.

Antes de empezar

Necesitás Git 2.23 o posterior, un remote configurado y una shell POSIX. En Windows, ejecutá estos comandos en Git Bash o WSL. La instalación por npm también requiere Node.js y npm.

El ejemplo supone que la rama del PR es feature/login, la rama de integración es main y ambas existen en origin. Reemplazá esos nombres por los de tu repositorio y empezá con el working tree limpio.

Estos comandos reciben nombres de ramas. El 123 de arriba corresponde a GitHub CLI; git review start recibe feature/login, en lugar de un número o una URL de PR.

Instalá y configurá

npm install -g git-review-workflow
git review --version
git config reviewworkflow.base main

La base se configura para este repositorio. Elegí la rama donde tu equipo integra los PRs, como main o develop. Para Homebrew, PowerShell o una instalación sin Node, consultá la guía de instalación.

Abrí el PR completo

git review start feature/login

Por defecto, actualiza el remote y revisa el tip de su rama. Crea review/feature/login con HEAD en el merge-base y deja el cambio completo del PR staged en el working tree.

git diff --cached

Ese diff es ahora el PR que estás revisando. Abrí el proyecto en tu editor, seguí llamadas fuera del diff y ejecutá los comandos de preparación y tests propios del proyecto.

También podés empezar desde un panel de VS Code, JetBrains o Visual Studio, o la interfaz de terminal. Todos conducen el mismo flujo.

Comprobá el comportamiento y corregí si hace falta

Supongamos que el PR cambia la comprobación de un límite y sospechás que permite un intento de más. Cambiá la condición en tu editor y ejecutá el test correspondiente.

El comando de tests depende del proyecto. Uno de Node podría usar npm test; seguí las instrucciones del repositorio.

git review preview

Muestra las correcciones que hiciste respecto del código del PR. Te permite comprobar qué se va a extraer antes de terminar.

Terminá la revisión

git review finish
git diff --cached

El resultado por defecto es review-fixes/feature/login, basada en el tip del PR, con las correcciones que hayas hecho staged. Revisá ese diff antes de commitear. El resultado queda local: vos elegís cuándo commitearlo y cómo compartirlo con el autor.

Una revisión guiada también puede terminar sin correcciones de código. Leer el cambio y dejar observaciones ya es un uso completo del flujo.

Dale un orden de lectura a un PR grande

Un walkthrough es un archivo Markdown con un orden para leer los archivos cambiados y un motivo por entrada. Para un cambio de login, el orden podría ser:

1. Leer la política para entender el límite previsto.
2. Leer el middleware que lo aplica.
3. Leer los tests de borde para comprobar el comportamiento.

El autor o un agente puede preparar ese recorrido junto con el cambio. Si el PR no tiene uno, el revisor puede preparar su propio orden local. La introducción al walkthrough explica ambos caminos.

El recorrido propone una ruta por el código. Vos seguís inspeccionando la implementación y comprobando su comportamiento.