Empieza a trabajar con Pull Request

Trabajar con repositorios de código y control de versiones está a la orden del día en el modo de trabajo de muchos desarrolladores, estas herramientas ayudan a la gestión de los cambios en un sistema de archivos y facilitan la colaboración dentro de los equipos. La herramienta de control de versiones más conocida y utilizada a día de hoy es Git, aunque existen otras como SVN o Mercurial.

Git es una herramienta flexible y no existe una única manera correcta de cómo trabajar con ella, por eso es importante que el equipo de desarrollo se ponga de acuerdo en el flujo de trabajo a utilizar al inicio del proyecto para que este sea lo más productivo posible. 

Las distintas maneras de como usar GIT dentro de un equipo de desarrollo se llaman GIT Workflows, existen tantas como equipos pero con el tiempo se han ido definiendo y poniendo nombre a los flujos de trabajo más habituales, algunos de ellos son Basic Workflow, Feature Branch Workflow, Forking Workflow, Gitflow, etc.   

Uno de los flujos más utilizados en proyectos colaborativos es trabajar mediante Pull Request (Forking Workflow). Una de las principales características es que cada desarrollador trabajará con dos repositorios, uno privado y uno compartido. Esta forma de colaboración permite una vía para que cualquier desarrollador proponga cambios en el código sin necesidad de tener acceso de escritura al repositorio central, la persona o personas encargadas de administrar ese repositorio central pueden revisar los cambios, rechazarlos, aceptarlos e integrarlos en el código o comentar y debatir ciertos aspectos del commit con el desarrollador.

Finalmente, si el cambio es aceptado, el commit pasará a formar parte del repositorio oficial. 👏👏👏

Si quieres empezar a colaborar en un repositorio mediante pull request a continuación te detallamos desde 0 los pasos que debes seguir:

1. Vamos al repositorio central, puede estar en GitHub, Bitbucket, GitLab, etc.
2. Creamos un fork del repositorio central, esta opción nos copiará el repositorio en nuestra cuenta.
3. Clonamos nuestro repositorio en nuestro entorno de trabajo. (git clone)
4. Si ejecutamos “git remote -v” veremos los remotes que tenemos configurados. En este momento deberíamos tener sólo origin que apunta a nuestro repositorio. Tendremos que añadir un nuevo remote para sincronizarnos con el repositorio central. Normalmente a este remote lo llamaremos upstream.
5. Para empezar a trabajar creamos una rama a partir de la rama principal (master)
6. Realizamos las modificaciones en el código necesarias y hacemos un nuevo commit con los cambios. Hacemos push de nuestra nueva rama o nuestro repositorio (remote origin).
7. Desde tu gestor de repositorios entramos en el fork y creamos un nuevo Pull Request (PR).
8. El PR aparecerá en el repositorio central para ser validado por otros desarrolladores.
9. Cuando el PR finalmente es aprobado se actualiza la rama master. El merge con la rama master se realiza dependiendo de las merging strategies acordadas para el repositorio. Pueden ser las siguientes:
   1. Fast forward:
      • Deberás ir a la rama master de tu repo y actualizarla con el upstream en caso que no esté igual que el repositorio central.
      • Cambias a tu rama y realizas un rebase de la master.
      • Con los cambios vuelves a hacer un commit  / push a tu rama.
      • Automáticamente tu PR se actualiza en el repositorio central.
      • Cuando se aprueba el PR se mergea con el repositorio central mediante fast forward.
   2. Merge-commit
      • Cuando se aprueba se realiza un merge con el repositorio central y crea un commit del merge de tu rama con la master.
   3. Squash
      • Se juntan todos los commits del PR en uno solo.
10. Se puede definir en el equipo  una persona encargada de integrar los PR al repositorio central o cada desarrollador se hace cargo de ello cuando ha recibido las suficientes validaciones.
11. Una vez que se ha integrado la rama el resto de desarrolladores del equipo podrán actualizar su rama principal (master).

Por último estas son algunas buenas prácticas a tener en cuenta al utilizar esta metodología de trabajo:

• Crear una rama para cada feature y por cada Pull Request.
• Crear siempre las ramas nuevas a partir de la rama master a ser posible con el último estado del upstream, para no depender de ramas o código que no esté en el repositorio central.
• No olvidarse de hacer rebase o merge del central antes de enviar el PR.