Veamos un flujo de trabajo con Git para gestionar y aprobar un Pull Request (PR) en un repositorio remoto compartido. El flujo de trabajo se ha comprobado que funciona correctamente en repositorios remotos gestionados en Bitbucket.
Suponemos un equipo formado por 3 desarrolladores (Ana, Lucía y Carlos) que están trabajando sobre un repositorio compartido utilizando el flujo de trabajo denominado Gitflow (ver el post de Vicent Driessen). En la rama develop se integran las features que se van desarrollando en ramas independientes.
Se ha definido la política de que antes de integrar una rama de característica se debe realizar un Pull Request en Bitbucket y algún otro miembro del equipo debe comprobar su funcionamiento y dar el visto bueno. La integración la realizará el mismo desarrollador que ha creado el Pull Request. Aunque Bitbucket proporciona la opción de cerrar el PR desde la interfaz web, utilizaremos comandos Git en el repositorio local para hacerlo.
Un ejemplo del flujo de trabajo:
Ana abre una feature creando la rama feature10, la sube a Bitbucket, realiza commits y cuando termina la característica comprueba que la rama se mezcla bien en develop y crea un PR en Bitbucket.
Lucía revisa el PR, se da cuenta de que faltan un par de cambios y pide a Ana que los termine.
Ana realiza los cambios en la rama, realiza la integración en develop y cierra el PR.
Lucía y Carlos actualizan sus repositorios locales.
Comandos Git para implementar este flujo de trabajo:
<h1>1. Ana abre la feature y crea el PR en Bitbucket</h1>$ git checkout -b feature10
$ git push -u origin feature10
$ git add .
$ git commit -m "Cambio"
$ git push
$ git checkout develop
$ git pull
$ git merge feature10
<Se crea el PR en Bitbucket>
<h1>Se deshace el merge</h1>$ git reset --merge ORIG_HEAD
$ git checkout feature10
Si el merge en develop genera un conflicto (o bien ficheros en conflicto, o tests que no pasan), se deshace el merge, se añaden cambios en la rama feature10 para evitar los conflictos y se vuelve a probar el merge con develop. La idea es asegurarse de que en el momento de hacer el PR no existe ningún conflicto entre la rama y develop.
<h1>Si el merge en develop no es OK</h1> <h1>Se deshace el merge</h1>$ git reset --merge ORIG_HEAD
$ git checkout feature10
$ git add .
$ git commit -m "Arreglados conflictos con develop"
$ git push
$ git checkout develop
$ git merge feature10
<Se crea el PR en Bitbucket>
<h1>Se deshace el merge</h1>$ git reset --merge ORIG_HEAD
<h1>Y se cambia a la rama a la espera de que un compañero apruebe el PR</h1>$ git checkout feature10
$ git pull
$ git checkout feature10
$ git checkout develop
$ git merge feature10
$ git reset --merge ORIG_HEAD
$ git checkout feature10
<h1>Añade los cambios</h1>$ git add .
$ git commit -m "Cambios añadidos"
$ git push
$ git checkout develop
$ git merge --no-ff -m "Integrado PR (pull request #21)" feature10
pull request #21
aparecerá en lal web de Bitbucket como un enlace a la página del PR</h1>
<h1>Sube el merge a Bitbucket y esto cierra el PR</h1>
$ git push
$ git push --delete origin feature10
$ git branch -d feature10
$ git checkout develop
$ git pull
$ git branch -d feature10
$ git remote prune origin
Pull requests