Tabla de Contenidos
Pull Requests
Sección perteneciente al curso Control de versiones con Git Avanzado.
Introducción
Las pull requests son un sistema de revisión del código que se utiliza en equipos muy grandes o donde cualquier persona puede colaborar.
Se basa en que, como desarrollador, yo no voy a poder hacer un merge a develop sino que abriremos una solicitud al equipo de revisión para que mire el código de mi rama y, si todo va bien, la vuelquen a develop.
Creación de pull request y discusión del código
En equipos pequeños, la metodología es, como desarrollador, vamos contribuyendo al proyecto a través de la rama develop.
Sin embargo, en equipos más grandes o proyectos open source, se suele utilizar el método de las pull requests. El código no se sube directamente a develop sino que alguien tiene que revisarlo y luego hacer merge a develop.
El repositorio remoto se configura de manera que los desarrolladores pueden descargarse la rama develop, pero no subirla (hacer el merge), es decir, tiene permiso de solo lectura.
Las pull requests existen en el servidor, no en nuestros equipos locales.
Hay un encargado (o varios) de revisar las peticiones PR (pull request) y de realizar el merge de las ramas a develop.
Cuando abrimos una pull request, subimos nuestra rama de feature e indicamos que esa rama la queremos fusionar con develop.
Puede abrirse un espacio de discusión sobre el código.
Cuando se haya aceptado y fusionado nuestra pull requests, se nos notificará y nosotros, en nuestro repositorio local tendremos que actualizar:
git pull develop
Entonces, podremos borrar nuestra rama local feature.
Pull Requests: caso práctico
Creamos un repositorio remoto.
Si somos nosotros los encargados de los pull request, vamos a nuestro repositorio local, iniciamos un repositorio git y añadimos el repositorio remoto:
git init git remote add origin <URL_REPOSITORIO_REMOTO>
Creamos una rama y la subimos:
git checkout master git push -u origin master
Ahora creamos y vamos a la rama develop:
git checkout develop
La subimos y pedimos que la trackee:
git push -u origin develop
Ahora que en el repositorio remoto hay ramas, hay que irse a las opciones y buscar los permisos de las ramas. Entonces, estableceremos que la rama develop tendrá permisos de escritura para el administrador y que los usuarios que seleccionemos tendrán permiso para fusionar a través de pull requests.
La rama master debería quedar configurada para que no permita pull requests y que solo un administrador pueda hacer cambios en ella.
En nuestro repositorio local, trabajamos sobre una rama, por ejemplo feature/titulo y la subo al repositorio remoto:
git push -u origin feature/titulo
En el repositorio remoto abriremos una pull request. Lo primero es indicar la rama origen (feature/titulo) y la rama destino (develop) y luego completar información como el commit y quién la va a revisar.
Al revisor le llegará la pull request y podrá revisar los cambios. Si está todo correcto, puede aprobarla y finalmente hacer la fusión.
Se avisará al desarrollador que pidió la pull request, así que podrá actualizar en local:
git checkout develop git pull
Y podremos borrar la rama local:
git branch -d feature/titulo
Pull Requests con conflictos
Cuando una pull request pueda generar algún conflicto, este no se puede solucionar en el repositorio remoto. No será posible hacer el merge en remoto.
Hay que resolver en local. El desarrollador se descargará la rama que crea el conflicto y hará un rebase de su rama a develop. Este rebase encontrará el conflicto, el desarrollador lo resolvería y luego subiría la rama.
Conclusión
En un equipo que trabaje con pull request debemos tener claro el flujo de trabajo: creamos una rama local temporal, la subimos, creamos la pull request en el servidor indicando de qué rama a qué rama queremos la fusión. Al cerrarse la pull request, podremos descargarnos la rama develop y borrar mi rama temporal.
Recursos
- Capítulo del libro Pro Git sobre contribuciones a proyectos en GitHub: