Realizar una pull request

Realizar una solicitud de incorporación de cambios

Las pull requests son una funcionalidad que facilita la colaboración entre desarrolladores que usan Bitbucket. Ofrecen una interfaz web intuitiva para debatir los cambios propuestos antes de integrarlos en el proyecto oficial.

Flujos de trabajo de Git: Solicitudes de incorporación de cambios en Bitbucket

En su forma más simple, las pull requests son un mecanismo para que los desarrolladores notifiquen a los miembros de su equipo que han terminado una funcionalidad. Una vez la rama de funcionalidades está lista, el desarrollador realiza la pull request mediante su cuenta de Bitbucket. Así, todas las personas involucradas saben que deben revisar el código y fusionarlo con la rama master.

Pero la solicitud de incorporación de cambios es mucho más que una notificación: es un foro especializado para debatir sobre una función propuesta. Si hay algún problema con los cambios, los miembros del equipo pueden publicar feedback en las solicitudes de incorporación de cambios e incluso modificar la función al enviar confirmaciones de seguimiento. El seguimiento de toda esta actividad se realiza directamente desde la solicitud de incorporación de cambios.

Flujos de trabajo de Git: Actividad en una solicitud de incorporación de cambios

En comparación con otros modelos de colaboración, esta solución formal para compartir confirmaciones crea un flujo de trabajo mucho más perfeccionado. SVN y Git pueden enviar automáticamente correos electrónicos de notificación mediante un script sencillo. No obstante, en lo que respecta a hablar sobre los cambios, los desarrolladores suelen depender de los hilos de correos electrónicos. Esto puede resultar peligroso, sobre todo cuando se trabaja con confirmaciones de seguimiento. Las solicitudes de incorporación de cambios vuelcan toda esta información en una interfaz de usuario sencilla junto a tus repositorios de Bitbucket.

Anatomía de una solicitud de incorporación de cambios

Cuando realizas una pull request, lo que haces es solicitar que otro desarrollador (por ejemplo, el mantenedor del proyecto) incorpore (o haga un pull) una rama de tu repositorio al suyo. Por tanto, para realizar esta solicitud, debes proporcionar la siguiente información: el repositorio de origen, la rama de origen, el repositorio de destino y la rama de destino.

Flujos de trabajo de Git: Solicitudes de incorporación de cambios

Bitbucket establece estos valores en un parámetro predeterminado lógico. No obstante, según tu flujo de trabajo de colaboración, tu equipo tendrá que especificar valores distintos. El diagrama anterior muestra una solicitud de incorporación de cambios que solicita que se fusione una rama de función con la rama maestra oficial, pero hay otras muchas formas de usar las solicitudes de incorporación de cambios.

Funcionamiento

Las pull requests se pueden usar junto con Feature Branch Workflow (Workflow de ramas de funcionalidades), Gitflow Workflow (Workflow de Gitflow) o Forking Workflow (Workflow de bifurcación). Sin embargo, como las pull requests requieren o bien dos ramas distintas, o bien dos repositorios distintos, no funcionan con Centralized Workflow (Workflow centralizado). El uso de pull requests con cada uno de estos workflows es ligeramente distinto, pero el proceso general es el siguiente:

  1. Un desarrollador crea una función en una rama especializada de su repositorio local.

  2. El desarrollador envía la rama a un repositorio de Bitbucket público.

  3. El desarrollador envía una solicitud de incorporación de cambios mediante Bitbucket.

  4. El resto del equipo revisa el código, debate sobre él y aplica modificaciones.

  5. El responsable del mantenimiento del proyecto fusiona la función con el repositorio oficial y cierra la solicitud de incorporación de cambios.

El resto de esta sección describe cómo se puede sacar partido de las solicitudes de incorporación de cambios en flujos de trabajo de colaboración diferentes.

Flujo de trabajo de rama de función con solicitudes de incorporación de cambios

Feature Branch Workflow (Workflow de ramas de funcionalidades) usa un repositorio compartido de Bitbucket para gestionar la colaboración, de modo que los desarrolladores crean funcionalidades en ramas aisladas. Pero, en lugar de fusionarlas inmediatamente con la master, deben abrir una pull request para iniciar un debate en torno a la funcionalidad antes de integrarla en el código base principal.

Solicitud de incorporación de cambios: Flujo de trabajo de rama de función

Solo hay un repositorio público en Feature Branch Workflow (Workflow de ramas de funcionalidades), por lo que el repositorio de destino y el de origen de la pull request siempre serán el mismo. Generalmente, el desarrollador especificará su rama de funcionalidades como la rama de origen y la rama master como la de destino.

Después de recibir la solicitud, el mantenedor del proyecto debe decidir qué hacer. Si la funcionalidad está lista, puede sencillamente fusionarla con la rama master y cerrar la solicitud. Pero si hay algún problema con los cambios propuestos, puede publicar su feedback en la pull request. Los commits aparecerán justo al lado de los comentarios relevantes.

También es posible enviar una solicitud de incorporación de cambios para una función incompleta. Por ejemplo, si un desarrollador está teniendo problemas para incorporar un requisito concreto, puede enviar una solicitud de incorporación de cambios con su trabajo en curso. Otros desarrolladores pueden proporcionar sugerencias en la solicitud de incorporación de cambios o incluso corregir el problema con confirmaciones adicionales.

Flujo de trabajo de Gitflow con solicitudes de incorporación de cambios

El flujo de trabajo de Git es similar al flujo de trabajo de rama de función, pero define un modelo de creación de ramas rígido y diseñado con la publicación del proyecto en mente. Añadir una solicitud de incorporación de cambios al flujo de trabajo de Gitflow les proporciona a los desarrolladores un lugar cómodo para hablar sobre una rama de publicación o una rama de mantenimiento mientras trabajan en ellas.

Solicitudes de incorporación de cambios: Flujo de trabajo de Gitflow Solicitudes de incorporación de cambios: Flujo de trabajo de Gitflow 2

La mecánica de las solicitudes de incorporación de cambios del flujo de trabajo de Gitflow es exactamente la misma que la que se ha explicado en la sección anterior: un desarrollador solo tiene que enviar una solicitud de incorporación de cambios cuando se tiene que revisar una rama de corrección, publicación o función, y el resto del equipo recibirá una notificación mediante Bitbucket.

Generalmente, las funcionalidades se fusionan con la rama develop, mientras que las ramas de versiones y de correcciones se fusionan con las ramas develop y master. Las pull requests se pueden usar para gestionar formalmente todas estas fusiones.

Flujo de trabajo de bifurcación con solicitudes de incorporación de cambios

En Forking Workflow (Workflow de bifurcación), un desarrollador envía una funcionalidad completada a su propio repositorio público en lugar de a uno compartido. Después, realiza una pull request para comunicar al mantenedor del proyecto que está lista para su revisión.

La notificación realizada por las solicitudes de incorporación de cambios resulta especialmente útil en este flujo de trabajo, ya que el responsable del mantenimiento del proyecto no tiene forma de saber cuándo ha añadido nuevas confirmaciones al repositorio de Bitbucket uno de los desarrolladores.

Solicitudes de incorporación de cambios: Flujo de trabajo de bifurcación

Puesto que cada desarrollador tiene su propio repositorio público, el repositorio de origen de la pull request será distinto a su repositorio de destino. El repositorio de origen es el repositorio público del desarrollador y la rama de origen es la que contiene los cambios propuestos. Si el desarrollador está intentando fusionar la funcionalidad con el código base, el repositorio de destino es el proyecto oficial y la rama de destino es la master.

Las pull requests también se pueden usar para colaborar con otros desarrolladores fuera del proyecto oficial. Por ejemplo, si un desarrollador trabaja con un compañero de equipo, puede realizar una pull request utilizando el repositorio Bitbucket de su compañero de equipo como destino en lugar del proyecto oficial. En tal caso, la rama de funcionalidades de origen y destino sería la misma.

Solicitudes de incorporación de cambios: Flujo de trabajo de bifurcación

Los dos desarrolladores pueden hablar sobre la función y desarrollarla desde la solicitud de incorporación de cambios. Cuando acaben, uno de ellos enviará otra solicitud de incorporación de cambios en la que pide fusionar la función con la rama maestra oficial. Este tipo de flexibilidad hace que las solicitudes de incorporación de cambios sean una herramienta de colaboración en el flujo de trabajo de bifurcación muy potente.

Ejemplo

En el siguiente ejemplo se muestra cómo las solicitudes de incorporación de cambios se pueden usar en el flujo de trabajo de bifurcación. Se aplica de igual modo a los desarrolladores que trabajan en equipos pequeños y a un desarrollador de terceros que contribuye a un proyecto de código abierto.

En el ejemplo, Mary es desarrolladora y John es el responsable del mantenimiento del proyecto. Ambos disponen de sus propios repositorios de Bitbucket públicos, y el proyecto oficial se encuentra en el de John.

Mary bifurca el proyecto oficial

Solicitudes de incorporación de cambios: Bifurcar el proyecto

Para empezar a trabajar en el proyecto, Mary primero debe realizar bifurcaciones en el repositorio Bitbucket de John. Para ello, solo tiene que iniciar sesión en Bitbucket, ir al repositorio de John y hacer clic en el botón Fork.

Solicitud de incorporación de cambios: Bifurcar en Bitbucket

Después de rellenar el nombre y la descripción del repositorio bifurcado, dispondrá de una copia en servidor del proyecto.

Mary clona su repositorio de Bitbucket

Solicitud de incorporación de cambios: Clonar el repositorio de Bitbucket

A continuación, Mary tiene que clonar el repositorio de Bitbucket que acaba de bifurcar. Esto le proporcionará una copia de trabajo del proyecto en su equipo local. Puede hacerlo mediante el siguiente comando:

git clone https://user@bitbucket.org/user/repo.git

Ten en cuenta que git clone crea un origin remoto de forma automática que apunta al repositorio bifurcado de Mary.

Mary desarrolla una nueva función

Solicitudes de incorporación de cambios: Desarrollar una nueva función

Antes de empezar a escribir el código, Mary tiene que crear una nueva rama para la función. Es la rama que usará como rama de origen para la solicitud de incorporación de cambios.

git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"

Mary puede utilizar todos los commits que necesite para crear la funcionalidad. Y, si el historial de la funcionalidad está más desordenado de lo que le gustaría, puede usar la reorganización interactiva para eliminar o combinar los commits innecesarios. En los proyectos más grandes, limpiar el historial de una funcionalidad hace que al mantenedor del proyecto le resulte mucho más sencillo ver lo que ocurre en la pull request.

Mary envía la función al repositorio de Bitbucket

Solicitudes de incorporación de cambios: Enviar una función al repositorio de Bitbucket

Una vez completada su funcionalidad, Mary envía la rama de funcionalidades a su propio repositorio Bitbucket (no al oficial) con un simple git push:

git push origin some-branch

Esto hace que los cambios estén disponibles para el responsable del mantenimiento del proyecto (o para cualquier colaborador que pueda necesitar acceso a ellos).

Mary crea una solicitud de incorporación de cambios

Solicitud de incorporación de cambios: Crear solicitud de incorporación de cambios

Una vez que la rama de funcionalidades está en Bitbucket, Mary puede crear la pull request por medio de su cuenta de Bitbucket yendo a su repositorio bifurcado y haciendo clic en el botón Pull request, situado en la esquina superior derecha. Se abrirá un formulario que asignará de forma automática el repositorio de Mary como el repositorio de origen y le pedirá que indique la rama de origen, el repositorio de destino y la rama de destino.

Mary quiere fusionar su funcionalidad con el código base principal, de modo que la rama de origen es su rama de funcionalidades, el repositorio de destino es el repositorio público de John y la rama de destino es master. También debe proporcionar un título y una descripción para la pull request. Si hay otras personas que deban aprobar el código además de John, las puede introducir en el campo Reviewers (Revisores).

Solicitud de incorporación de cambios: Bitbucket

Después de crear una solicitud de incorporación de cambios, se enviará una notificación a John mediante el panel de Bitbucket y, de forma opcional, por correo electrónico.

John revisa la solicitud de incorporación de cambios

Solicitud de incorporación de cambios: Solicitudes de incorporación de cambios de Bitbucket

John puede acceder a todas las pull requests que se han realizado haciendo clic en la pestaña Pull request de su propio repositorio Bitbucket. Al hacer clic en la pull request de Mary, se le mostrará una descripción de la solicitud, el historial de commits de la funcionalidad y una comparación de los cambios que contiene.

Si cree que la funcionalidad está lista para integrarse en el proyecto, todo lo que tiene hacer es hacer clic en el botón Merge (Fusionar) para aprobar la pull request y fusionar la funcionalidad de Mary con su rama master.

No obstante, para este ejemplo, imaginemos que John ha encontrado un pequeño error en el código de Mary y que necesita que lo arregle antes de realizar la fusión. Para ello, puede publicar un comentario de forma general en la solicitud de incorporación de cambios o puede comentar en una confirmación concreta del historial de la función.

Solicitud de incorporación de cambios: Comentar

Mary añade una confirmación de seguimiento

Si Mary tiene alguna duda sobre el feedback, puede responder en la solicitud de incorporación de cambios, de forma que se use como un foro de debate sobre su función.

Para corregir el error, Mary añade otra confirmación a su rama de función y la envía a su repositorio de Bitbucket, como hizo la primera vez. Esta confirmación se añade de forma automática a la solicitud de incorporación de cambios original, y John puede revisar los cambios de nuevo junto al comentario original.

John acepta la solicitud de incorporación de cambios

Finalmente, John acepta los cambios, fusiona la rama de funcionalidades con la master y cierra la pull request. Ahora la funcionalidad está integrada en el proyecto y cualquier otro desarrollador que trabaje en él puede enviarla a su propio repositorio local usando el comando estándar git pull.

Hacia dónde ir

Ahora ya deberías tener todas las herramientas que necesitas para comenzar a integrar pull requests en tu workflow existente. Recuerda que las pull requests no son un sustitutivo de ningún workflow colaborativo basado en Git, sino más bien un cómodo añadido que hace la colaboración más accesible a todos los miembros de tu equipo.

¿Quieres probar las solicitudes de incorporación de cambios?

Prueba este tutorial interactivo.

Comienza ahora