Infraestructura 0: Pull Request

Un pull request, o merge request en otros sistemas de trabajo en equipo como GitLab, es el mecanismo habitual de desarrollo dentro de un equipo. Consiste en una presentación de los cambios hechos de una rama de git a la rama principal (lo que se denomina diff) a través de una serie de commit (que se pueden examinar por separado), que da la oportunidad al resto del equipo (o a cualquiera que tenga acceso de lectura) a comentar, sugerir cambios y eventualmente aceptar esos cambios.

Es un mecanismo fundamental en desarrollo ágil porque permite asegurar la calidad del código (o de lo que se haya incluido en el repositorio) más allá de los tests que se puedan hacer automáticamente: permite aplicar las reglas de nombres de variables, por ejemplo, o reglas de alto nivel sobre el código como identificar antipatrones y solicitar a la persona o persona que hace el PR que lo corrija.

Para hacer un PR se siguen estos pasos

Crear una rama de la rama principal, o en general de cualquier otra rama
Hacer push de esa rama del repositorio local a GitHub (desde línea de órdenes se hace con push -u para que cree una rama; tras eso habrá que poner el nombre de esa rama que generalmente será el mismo que el de la rama local
En ese push -u el propio GitHub contesta con un URL que se puede usar para crear el pull request. Si no, se navega hasta situarse en la rama en GitHub y una vez más éste te presentará un botón para crear un PR siempre que haya diferencias con otra rama.

Un PR lo puede crear cualquier persona que pueda leer el repo, porque se puede hace run fork a su propio repositorio; de hecho, si editas un fichero en un repositorio en el que no tienes privilegios automáticamente GitHub creará ese fork y, cuando guardes los cambios (haciendo un commit) te preguntará si quieres hacer un PR.

El resto de los participantes en el repositorio recibirán una notificación de la creación de la rama, y podrán participar en la revisión de la misma. En esta, se puede tanto comentar línea por línea como sugerir cambios (usando el icono correspondiente). En este caso el que haya creado el PR podrá aceptar o no el cambio, creando un commit con el autor de la sugerencia.

La buena práctica es reaccionar a todos los comentarios. Reaccionar implica o hacer un cambio a la línea en la que se ha sugerido el cambio, en cuyo caso el comentario “desaparece” del interfaz como resuelto. A veces el comentario requiere cambios en otro lugar, en cuyo caso la buena práctica es hacer ese cambio, anotar el código del commit en el que se ha hecho, y “resolver” el comentario indicando “Resuelto en abcd1234” (o el número del commit correspondiente, se puede copiar del interfaz).

En general, no se aprueba el PR hasta que no se han resuelto todos los comentarios; cuando se hace se puede pedir una revisión del resto del equipo (a través del botón correspondiente en GitHub) o indicarlo con una referencia @ a la persona que quieres que revise (puede ser una persona externa al repo).

Por otro lado, existen una serie de buenas prácticas a la hora de abrir un PR, como que siempre se tiene que referir a un issue abierto, y que debe tener un ámbito claro y determinado. Pero el ámbito de este documento no incluye ese tipo de prácticas, así que baste dejar constancia de ese hecho.