Flujo de trabajo de ramas de función en Git

La idea principal que subyace al flujo de trabajo de ramas de función es que el desarrollo de una función debe llevarse a cabo en una rama especializada, en lugar de en una rama master. Este aislamiento permite que varios desarrolladores trabajen en una función concreta sin perturbar el contenido del código base principal. También implica que la rama master no contendrá en ningún caso código erróneo, lo que supone una gran ventaja para los entornos de integración continua.

El desarrollo de la función de aislamiento también permite aprovechar solicitudes de incorporación de cambios, que constituyen una forma de iniciar debates en torno a una rama, ya que brindan a otros desarrolladores la oportunidad de dar el visto bueno a una función antes de que esta se integre en el proyecto oficial. Otra posibilidad es que, si te atascas en medio de una función, abras una solicitud de incorporación de cambios en la que pidas sugerencias a tus compañeros. El caso es que las solicitudes de incorporación de cambios hacen que a tu equipo le resulte increíblemente fácil comentarse el trabajo de forma recíproca.

El flujo de trabajo de ramas de función en Git es un flujo de trabajo que puede estar compuesto por diversos elementos y que pueden aprovechar otros flujos de trabajo de Git de alto nivel. En la página de descripción general de los flujos de trabajo de Git ya comentamos otros flujos de trabajo de Git. El flujo de trabajo de ramas de función en Git es un modelo de creación de ramas centrado, lo que significa que es un marco que sirve de patrón para la gestión y creación de ramas. Otros flujos de trabajo están más centrados en el repositorio, pero el flujo de trabajo de ramas de función en Git se puede incorporar a otros flujos de trabajo. Gitflow y los flujos de trabajo de bifurcación de Git usan tradicionalmente un flujo de trabajo de ramas de función en Git con respecto a sus modelos de creación de ramas.

Funcionamiento


El flujo de trabajo de ramas de función presupone la existencia de un repositorio central y que una rama master representa el historial oficial del proyecto. En vez de confirmar directamente en la rama master local, los desarrolladores crean una rama nueva cada vez que empiezan a trabajar en una función nueva. Las ramas de función deben tener nombres descriptivos como, por ejemplo, "elementos-animados-menu" o "incidencia-#1061". La idea es dar un propósito claro y muy concreto a cada rama. Git no hace ninguna distinción técnica entre la rama master y las de función, por lo que los desarrolladores pueden editar, preparar y confirmar cambios en una rama de función.

Además, las ramas de función pueden (y deben) enviarse al repositorio central, lo que permite compartir una función con otros desarrolladores sin tocar nada del código oficial. Dado que la rama master es la única "especial", almacenar varias ramas de función en el repositorio central no plantea ningún problema. Indudablemente, esta también supone una forma práctica de hacer una copia de seguridad de las confirmaciones locales de todo el mundo. A continuación, presentamos un recorrido por todo el ciclo de vida de una rama de función.

Empieza por la rama maestra

Todas las ramas de función se crean a partir del último estado del código de un proyecto. En esta guía se da por sentado que dicho código se mantiene y actualiza en la rama master.

 git checkout master git fetch origin git reset --hard origin/master

Con esta acción se pasa el repositorio a la rama master, se incorporan los cambios de las últimas confirmaciones y se restablece la copia local del repositorio de la rama master para que coincida con la última versión.

Crea una rama nueva

Debes utilizar una rama aparte para cada función o incidencia en la que trabajes. Cuando la hayas creado, extráela localmente para que todos los cambios que hagas se apliquen en dicha rama.

git checkout -b new-feature

Con esta acción, se extrae una rama llamada "new-feature" a partir de la master, y el indicador "-b" ordena a Git que la cree en caso de que esta no existiera ya.

Actualiza, añade, confirma y envía los cambios

En esta rama debes editar, preparar y confirmar los cambios como harías normalmente, y desarrolla la función con tantas confirmaciones como haga falta. Trabaja en la función y haz confirmaciones como harías siempre que uses Git. Cuando lo tengas todo listo, envía tus confirmaciones para actualizar así la rama de función en Bitbucket.

 git status git add  git commit

Envía la rama de función a una remota

Es recomendable enviar la rama de función al repositorio central, ya que esto actúa como una práctica copia de seguridad y, al colaborar con otros desarrolladores, les permite acceder para ver las confirmaciones efectuadas en la nueva rama.

git push -u origin new-feature

Este comando envía new-feature al repositorio central (el de origen), y el indicador "-u" la añade como rama de seguimiento remoto. Tras configurar la rama de seguimiento remoto, se puede invocar git push sin ningún parámetro para enviar automáticamente la rama new-feature al repositorio central. Para recibir comentarios sobre la nueva rama de función, crea una solicitud de incorporación de cambios en una solución de gestión de repositorios como Bitbucket Cloud o Bitbucket Server. A partir de ahí, podrás añadir revisores y asegurarte de que todo esté listo antes de fusionar.

Resuelve los comentarios

Ahora, tus compañeros de equipo podrán comentar y aprobar las confirmaciones enviadas. Resuelve sus comentarios localmente, confirma y envía los cambios sugeridos a Bitbucket. Las actualizaciones aparecen en la solicitud de incorporación de cambios.

Fusiona la solicitud de incorporación de cambios

Antes de fusionar, quizá tengas que resolver conflictos de fusión si otras personas han hecho cambios en el repositorio. Cuando tu solicitud de incorporación de cambios esté aprobada y libre de conflictos, podrás añadir tu código a la rama master. Debes fusionar desde la solicitud de incorporación de cambios en Bitbucket.

Solicitudes de incorporación de cambios

Aparte de aislar el desarrollo de funciones, las ramas permiten debatir los cambios mediante solicitudes de incorporación de cambios. En cuanto alguien termine una función, no deberá fusionarla inmediatamente en la rama master. En lugar de eso, deberá enviar la rama de dicha función al servidor central y presentar una solicitud de incorporación de cambios en la que pida fusionar sus incorporaciones a la master. De este modo, se da al resto de los desarrolladores una oportunidad de revisar los cambios antes de que estos pasen a formar parte de la base de código principal.

La revisión del código es una de las principales ventajas de las solicitudes de incorporación de cambios, pero lo cierto es que están diseñadas para ser una forma genérica de hablar sobre el código. Podemos concebirlas como un debate centrado en una rama en particular. Esto quiere decir que también se pueden utilizar en fases muy anteriores del proceso de desarrollo. Por ejemplo, si algún desarrollador necesita ayuda con alguna función en concreto, todo lo que tiene que hacer es presentar una solicitud de incorporación de cambios. Se notificará automáticamente a las partes interesadas, quienes podrán ver la pregunta justo al lado de las confirmaciones pertinentes.

En cuanto se acepta una solicitud de incorporación de cambios, el proceso propiamente dicho de publicar una función es en gran medida idéntico al del flujo de trabajo centralizado. En primer lugar, tienes que comprobar que la rama master local esté sincronizada con la master de nivel superior. Acto seguido, debes fusionar la rama de la función en la master y enviar la master actualizada de vuelta al repositorio central.

Las solicitudes de incorporación de cambios se pueden tramitar mediante soluciones de gestión de repositorios de productos tales como Bitbucket Cloud o Bitbucket Server. Consulta la documentación sobre las solicitudes de incorporación de cambios en Bitbucket Server para ver un ejemplo.

Ejemplo

A continuación, mostramos un ejemplo del tipo de situación en la que se utiliza el flujo de trabajo de creación de ramas de función. La situación es que un equipo que está revisando código relativo a una solicitud de incorporación de cambios para una función nueva. Este es solo uno ejemplo de los muchos fines para los que se puede utilizar este modelo.

Mary comienza una nueva función

Flujo de trabajo de ramas de función: confirmar cambios

Antes de empezar a desarrollar una función, Mary necesita una rama aislada en la que trabajar, para lo que puede solicitar una rama nueva mediante el siguiente comando:

git checkout -b marys-feature master

Este comando extrae una rama llamada marys-feature basada en la master, y el indicador "-b" ordena a Git que la cree en caso de que esta no existiera ya. En esta rama, Mary edita, prepara y confirma los cambios como de costumbre, y desarrolla la función con tantas confirmaciones como haga falta:

 git status git add  git commit

Mary se va a comer

Flujo de trabajo de ramas de función: git push

A lo largo de la mañana, Mary añade unas cuantas confirmaciones a la función. Antes de salir a comer, tiene la buena idea de enviar la rama de función al repositorio central. Esto actúa como una práctica copia de seguridad, pero si Mary estuviera colaborando con otros desarrolladores, también les permitiría a estos acceder a las confirmaciones iniciales.

git push -u origin marys-feature

Este comando envía marys-feature al repositorio central (el de origen), y el indicador "-u" la añade como rama de seguimiento remoto. Una vez configurada la rama de seguimiento, Mary puede invocar el comando git push sin ningún parámetro para enviar su función.

Mary termina la función

Flujo de trabajo de ramas de función: git push

Cuando Mary vuelve de comer, termina la función. Antes de fusionarla en la rama master, tiene que presentar una solicitud de incorporación de cambios mediante la cual informe al resto del equipo que ha terminado. Pero primero debe asegurarse de que el repositorio central tenga las confirmaciones más recientes:

git push

Después, debe presentar la solicitud de incorporación de cambios en su interfaz de usuario de Git en la que pida fusionar marys-feature en master, y los miembros del equipo recibirán una notificación automática. Lo maravilloso de las solicitudes de incorporación de cambios es que muestran comentarios junto a sus confirmaciones relacionadas, por lo que plantear preguntas sobre series de cambios concretos resulta tarea fácil.

Bill recibe la solicitud de incorporación de cambios

Flujo de trabajo de ramas de función: revisión de una solicitud de incorporación de cambios

Bill recibe la solicitud de incorporación de cambios, echa un vistazo a marys-feature y decide que desea aplicar unos cuantos cambios antes de integrarla en el proyecto oficial, y él y Mary mantienen un breve intercambio de opiniones a través de la solicitud de incorporación de cambios.

Mary aplica los cambios

Flujo de trabajo de ramas de función: revisiones de solicitudes de incorporación de cambios

Para meter los cambios, Mary sigue exactamente el mismo proceso que para crear la primera iteración de su función. Edita, prepara, confirma y envía las modificaciones al repositorio central. Toda su actividad se muestra en la solicitud de incorporación de cambios, y Bill puede seguir añadiendo comentarios durante el proceso.

Si quisiera, Bill podría extraer marys-feature a su propio repositorio local y trabajar en ella por su cuenta. Todas las confirmaciones que añadiera también se mostrarían en la solicitud de incorporación de cambios.

Mary publica la función

Flujo de trabajo de ramas de función: fusionar una rama de función

En cuanto Bill esté dispuesto a aceptar la solicitud de incorporación de cambios, alguien tendrá que fusionar la función en el proyecto estable (esto es algo que pueden hacer tanto Bill como Mary):

git checkout master git pull git pull origin marys-feature git push 

Este proceso suele dar lugar a una confirmación de fusión. A algunos desarrolladores les gusta esto porque es como una unión simbólica de la función con el resto de la base de código. Ahora bien, si estás en parte de una historia lineal, se puede reorganizar la fusión en el extremo de la rama master antes de ejecutar la fusión, lo que provoca una fusión con avance rápido.

Algunas interfaces de usuario automatizarán el proceso de aceptación de la solicitud de incorporación de cambios ejecutando todos estos comandos con solo hacer clic en el botón "Aceptar". Si en la tuya no es el caso, al menos debería poder cerrarla automáticamente cuando la rama de la función se fusione en la master.

Entretanto, John está haciendo exactamente lo mismo

Mientras Mary y Bill están trabajando en marys-feature y debatiendo al respecto en la solicitud de incorporación de cambios, John está haciendo exactamente lo mismo con su propia rama de función. Al aislar las funciones en ramas aparte, todo el mundo puede trabajar de forma independiente, pero sigue siendo vital compartir los cambios con otros desarrolladores si es preciso.

Resumen


En este documento, hemos examinado el flujo de trabajo de ramas de función en Git. Este flujo de trabajo ayuda a organizar las ramas centradas en conjuntos de funciones de un dominio de la empresa y a hacer un seguimiento de ellas. Otros flujos de trabajos de Git como, por ejemplo, el flujo de trabajo de bifurcación de Git y Gitflow, están centrados en el repositorio y pueden aprovechar el flujo de trabajo de ramas de función en Git para gestionar sus modelos de creación de ramas. En este documento hemos mostrado un ejemplo de código de alto nivel y un ejemplo ficticio de implementación del flujo de trabajo de ramas de función en Git. Algunas de las asociaciones más importantes que hay que hacer con este flujo de trabajo son las siguientes:

  • Está centrado en los patrones de creación de ramas.
  • Lo pueden aprovechar otros flujos de trabajos orientados al repositorio.
  • Fomenta la colaboración con los miembros del equipo mediante solicitudes de incorporación de cambios y revisiones de fusiones.

Utilizar git rebase durante las fases de revisión y fusión de una rama de función forzará la creación de un historial cohesivo de fusiones de funciones en Git. Un modelo de creación de ramas constituye una herramienta fantástica para fomentar la colaboración dentro de un entorno de equipo.

Estás a un solo clic de profundizar en los flujos de trabajo de Git leyendo nuestro completo tutorial sobre el flujo de trabajo Gitflow.

¿Listo para aprender a usar Git?

Prueba este tutorial interactivo.

Comienza ahora