Realizar una pull request
Pull requests are a feature that makes it easier for developers to collaborate using Bitbucket. They provide a user-friendly web interface for discussing proposed changes before integrating them into the official project.
En su forma más sencilla, las solicitudes de incorporación de cambios son un mecanismo para que los desarrolladores notifiquen a los miembros de su equipo que han terminado una función. Una vez la rama de función está lista, el desarrollador realiza la solicitud de incorporación de cambios mediante su cuenta de Bitbucket. Así, todas las personas involucradas saben que deben revisar el código y fusionarlo con la rama main
.
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.
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.
Bitbucket establece estos valores en un parámetro predeterminado lógico. No obstante, en función de 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 principal 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. The developer pushes the branch to a public Bitbucket repository.
3. The developer files a pull request via Bitbucket.
4. The rest of the team reviews the code, discusses it, and alters it.
5. The project maintainer merges the feature into the official repository and closes the pull request.
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.
Material relacionado
Git log avanzado
VER LA SOLUCIÓN
Aprende a usar Git con Bitbucket Cloud
Flujo de trabajo de rama de función con solicitudes de incorporación de cambios
El flujo de trabajo de ramas de función usa un repositorio compartido de Bitbucket para gestionar la colaboración, y los desarrolladores crean las funciones en ramas aisladas. Sin embargo, en lugar de fusionarlas inmediatamente con main
, deben abrir una solicitud de incorporación de cambios para iniciar un debate en torno a la función antes de integrarla en el código base principal.
Solo hay un repositorio público en el flujo de trabajo de ramas de función, por lo que el repositorio de destino y el de origen de la solicitud de incorporación de cambios siempre serán el mismo. Habitualmente, el desarrollador especificará su rama de función como la rama de origen y la rama principal
como la de destino.
Después de recibir la solicitud, el mantenedor del proyecto debe decidir qué hacer. Si la función está lista, puede sencillamente fusionarla con la rama main
y cerrar la solicitud. No obstante, si hay algún problema con los cambios propuestos, puede publicar su feedback en la solicitud de incorporación de cambios. Las confirmaciones de seguimiento 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.
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.
Por norma general, las funciones se fusionan con la rama develop
o de desarrollo, mientras que las ramas de publicación y de corrección se fusionan con las ramas develop
y main
o principal. Las solicitudes de incorporación de cambios 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.
Puesto que cada desarrollador tiene su propio repositorio público, el repositorio de origen de la solicitud de incorporación de cambios 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 función con el código base, el repositorio de destino es el proyecto oficial y la rama de destino es main
.
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.
Los dos desarrolladores pueden analizar 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 principal oficial. Con esta flexibilidad, las solicitudes de incorporación de cambios son una herramienta de colaboración muy potente en el flujo de trabajo de bifurcación.
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
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.
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
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
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
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
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 función con el código base principal, de modo que la rama de origen es su rama de función, el repositorio de destino es el repositorio público de John y la rama de destino es main
. También debe proporcionar un título y una descripción para la solicitud de incorporación de cambios. Si hay otras personas que deban aprobar el código además de John, las puede introducir en el campo Reviewers (Revisores).
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
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 John cree que la función está lista para integrarse en el proyecto, lo único que debe hacer es hacer clic en el botón Merge (Fusionar) para aprobar la solicitud de incorporación de cambios y fusionar la función de Mary con su rama principal
.
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.
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
Para terminar, John acepta los cambios, fusiona la rama de función con la principal y cierra la solicitud de incorporación de cambios. Ahora la función está integrada en el proyecto y cualquier otro desarrollador que trabaje en él puede incorporarla a su propio repositorio local mediante 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.
Compartir este artículo
Tema siguiente
Lecturas recomendadas
Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.