Como trabajar con pull request en Github

8 minutos de lectura

Fecha: 15/12/2020

Vamos a explicar como trabajar con pull request en Github y porque es tan necesario que aprendamos a hacerlo.

Una de las acciones que mas se usan en un entorno colaborativo son las pull request. Pues estas nos permiten que un tercero valide el código que queremos subir, o validarselo nosotros a él.

Si todo el mundo subiera sin control, por ejemplo a una rama master o dev, tendríamos varios problemas:

• Sería muy difícil que el conjunto del equipo estuviera al tanto de los cambios.
• Se fomentaría subir multitud de veces confirmaciones de código incompletas, en vez de trabajar con ramas y subir funcionalidades completas
• Otros miembros del equipo no podrían encontrar bugs antes de que el código llegue arriba
• Perdemos feedback valioso de los comentarios del resto del equipo
• El fomentar que se suba sin control en entornos de CI/CD puede provocar que los entornos estén gran parte del tiempo desplegando cambios

Por eso, para poner un poco de orden en todo esto, la estrategia a seguir es impedir que subamos a ciertas ramas nuestro código de forma directa. Tendremos que trabajar en ramas que creemos y que posteriormente se integraran con las ramas que bloqueamos mediante las pull request.

La pull request por tanto es simplemente una petición para mergear la rama donde se encuentra el código, con otra común que esta bloqueada. Y además la pull request debe ser aprobada o rechazada por un tercero (o varios, nosotros decidimos cuantos deben aprobarla), no por el que la crea.

Obviamente si estas trabajando en un proyecto tu solo esto deja de tener tanto sentido. Porque nadie te las podría aprobar, tendrías que permitirte aprobártelas tu mismo y eso no tiene sentido.

Como mucho podrías usarlo como un método disuasorio para que no subas tantos commits a las ramas master o dev (que son sobre las que se suele trabajar). En caso de que consideres que eres muy desordenado al hacerlo y que la historia de tu repositorio esta llena de commits inútiles.

Pero vamos al lio, ¿cómo nos ponemos a ello en Github?, voy a explicarlo paso a paso.

Como configuramos que nuestro proyecto use pull request

En primer lugar créate un repositorio o hazte un fork de alguno, yo en mi caso por acabar antes voy a forkearme el de react…

Aquí lo tengo, básicamente esto lo me ha creado un proyecto propio con todas las ramas, tags y código fuente que el original. Pero ahora es un proyecto mio y no tiene ninguna restricción es como si lo acabara de subir desde local…

Pongamos que en este proyecto vamos a trabajar varios y quiero activar las pull request. Lo primero que tengo que hacer es bloquear la rama por defecto donde se subirán los cambios, la rama master.

Para ello pulso en settings luego en branches y por último en el botón add rule, y con esto podemos establecer reglas sobre las ramas.

Una vez hemos hecho esto veremos la siguiente página donde tendremos que definir el patrón de la rama al que queremos asignar la regla. Como en mi caso quiero bloquear master no hace falta ninguna expresión regular, solamente escribir el nombre de la rama.

Luego tenemos una casilla que pone ‘Require pull request reviews before merging‘ esta es la clave, con ello estamos bloqueando subidas a la rama salvo que las hagamos a través de una pull request.

Al activarla tenemos un desplegable que dice ‘Required approving reviews‘. Esto sirve para que indiquemos cuantas personas necesitan aprobar la pull request para que se dispare el merge. Yo recomiendo una o dos personas al menos en un proyecto Scrum (donde la norma es que haya 3-9 personas) sino se convierte en un cacería constante de reviewers.

En mi caso marco solo uno, y por último voy a marcar la casilla ‘Include administrators‘ que obliga a que ellos también tengan que hacer las Pr’s. Porque no me gusta eso de que los administradores del proyecto tengan privilegios para saltarselo y subir «a saco».

Listo! Ya tenemos las pull request habilitadas en nuestro proyecto de Github. ¿Fácil verdad?. Veamos ahora que sucede si cambio algo en master e intento subirlo directamente. Voy a cambiar el readme por ejemplo y lo subo…

Como se puede apreciar he añadido los cambios en el readme y después hice un commit, hasta aquí todo correcto. Sin embargo, cuando después intente hacer push para subir los cambios a Github no me ha dejado.

El error a grandes rasgos nos está cantando que no puede subir directamente a esta rama porque esta protegida. Tambien indica que al menos 1 persona con acceso de escritura nos tiene que aprobar la PR.

Como crear una pull request

Como antes dijimos una pull request es una petición para mergear la rama donde se encuentra el código con otra común que esta bloqueada. De manera que este cambio nos lo tendríamos que llevar a una rama, y posteriormente subir esa rama a GitHub que es donde se crea la PR.

Esto es sencillo de hacer, aunque no es el tema de esta entrada, para hacer esto usamos los comandos:

Para crear la rama git branch nombreDeLaRama, luego nos posicionamos en ella. Para subirla git push —set-upstream origin nombreDeLaRama

Yo a la mía le llame «test» para no complicarme, ahora me voy a GitHub, y como ya tengo las dos ramas que quiero combinar puedo crear la PR.

Tan pronto como accedamos al repositorio podemos ver como ya ha detectado que hemos subido una nueva rama, y nos propone comparar y hacer la pull request.

Al pulsar en ese botón nos llevará a la página donde podemos crear finalmente la PR, veremos algo así…

Aquí podemos ver varias cosas:

1. Vemos las ramas que se están mergeando (en este caso la rama test sobre master)
2. Aquí es donde escribimos que hace nuestra pull request, cual es su funcionalidad, a que tarea corresponde, que pasos hay que seguir para probarla, etc…
3. Este es el botón para crearla definitivamente
4. Los commits que me estoy llevando al hacerla
5. Los cambios en el código que estoy introduciendo

Ahora para terminarla solamente nos queda pulsar el botón y listo!

Como aprobar una pull request

Con la PR ya creada solo falta que otro colaborador de nuestro proyecto revise nuestra subida y la apruebe (o la rechace si ve algo mal, por supuesto).

Yo he añadido otro usuario que tengo como colaborador y os voy a mostrar como tengo que hacer para aprobarla.

Entro con mi cuenta de colaborador y busco el repositorio. Una vez dentro tengo que ir a la pestaña de PRs y seleccionar la que quiero revisar. En este caso no es nada difícil porque solo hay una.

Pulso encima de ella y abrimos la PR, a continuación esto es lo que veremos…

Poco también que comentar de esta captura, simplemente pulsa en el link que te he marcado que pone ‘Add your review‘ que nos abrirá la siguiente página.

Aquí si que ya tenemos algo más que ver, en primer lugar git nos va a resaltar las diferencias que hay dentro de la rama que queremos mergear con la rama base. Yo simplemente edité una línea así que podéis ver en el punto 1 como se marca en rojo lo que antes había, y luego en verde lo nuevo, incluso subrayado en un verde más intenso está el cambio introducido.

La verdad es que es superintuitivo y aunque nadie te lo explique te das cuenta de como funciona y lo bien que se muestran los cambios.

Luego en el punto esta el botón ‘Review changes’ que es el que debemos pulsar para dar nuestra revisión, esto despliega el popup que veis. Y aquí tenemos 3 checks, para hacer 3 cosas distintas:

• Comment para comentar la PR y que el creador modifique algo que no está bien hecho, o revise porque rompe, o para lo que consideremos…
• Approve para aprobarla
• Request changes para pedirle que haga algún cambio, no necesariamente porque este mal programado sino porque necesitamos que la funcionalidad sea otra o no este del todo completa

La verdad es que me he encontrado que muchas veces tanto el Comment como el Request changes se usan indistintamente porque al final ambas sirven para dar feedback al autor, pero la primera sería mas genérica mientras que la otra son para temas de funcionalidad.

En cualquier caso para completar la PR lo que tenemos que hacer es obviamente aprobarla, puedes escribir igualmente un mensaje si lo deseas, y luego pulsar el botón ‘Submit review‘. Con esto ya casi hemos terminado.

Como se aprecia ahora la página muestra que los cambios que introduce nuestra PR han sido aprobados, que además no hay conflictos entre ambas ramas, y que por lo tanto podemos combinarlas. Para ello simplemente pulsa el botón verde ‘Merge pull request‘ y listo, ya has terminado!

No tiene más, así de sencillo es configurar tu proyecto para que use pull request, y como veis la rutina de trabajo para usarlas no tiene ningún secreto, es todo cuestión de ser responsables y no aprobarlas sin haber revisado realmente el código y comprobado que todo funciona.

Espero que os sirviera de ayuda y que quedara claro como trabajar con pull request en Github.