Flujo de trabajo de ramas de función en Git
La idea principal subyacente del 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 la rama main. Este aislamiento permite que varios desarrolladores trabajen en una función concreta sin modificar el contenido del código base principal. También implica que la rama main 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 centrado en la creación de ramas, 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. 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 la rama main representa el historial oficial del proyecto. En vez de confirmar directamente en la rama main local, los desarrolladores crean una rama 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 asignar un objetivo claro y muy concreto a cada rama. Git no hace ninguna distinción técnica entre la rama main 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 main es la única "especial", almacenar varias ramas de función en el repositorio central no supone 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 con la rama principal
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 main.
Material relacionado
Git log avanzado
VER LA SOLUCIÓN
Aprende a usar Git con Bitbucket Cloud
git checkout main
git fetch origin
git reset --hard origin/mainCreación del repositorio
Con esta acción se pasa el repositorio a la rama main, se incorporan los cambios de las últimas confirmaciones y se restablece la copia local del repositorio de la rama main 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-featureCon esta acción, se extrae una rama llamada "new-feature" a partir de la main, y la marca "-b" ordena a Git que la cree en caso de que esta no exista.
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 <some-file>
git commitEnví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-featureEste comando envía new-feature al repositorio central (el de origen), y la marca "-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 Data Center. 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 la solicitud de incorporación de cambios esté aprobada y libre de conflictos, podrás añadir tu código a la rama main. 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 termina una función, no la fusiona inmediatamente en la rama main, sino que envía la rama de dicha función al servidor central y presenta una solicitud de incorporación de cambios en la que solicita fusionar sus incorporaciones en la rama main. De este modo, se da al resto de los desarrolladores la 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 main local esté sincronizada con la rama main ascendente. Acto seguido, debes fusionar la rama de función en la main y enviar la rama main actualizada de vuelta al repositorio central.
Las solicitudes de incorporación de cambios se pueden facilitar con soluciones de gestión del código fuente, como Bitbucket Cloud.
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
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 mainEste comando extrae una rama llamada marys-feature basada en la rama main, y la marca "-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 <some-file>
git commitMary se va a comer
.svg?cdnVersion=2441)
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-featureEste comando envía marys-feature al repositorio central (el de origen), y la marca "-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
Cuando Mary vuelve de comer, termina la función. Antes de fusionarla en la rama main, tiene que presentar una solicitud de incorporación de cambios para informar al resto del equipo que ha terminado. Pero primero debe asegurarse de que el repositorio central tenga las confirmaciones más recientes:
git pushDespués, presenta la solicitud de incorporación de cambios en su interfaz de usuario de Git mediante la cual pide fusionar marys-feature en main. Los miembros del equipo, por su parte, recibirán una notificación automáticamente. Lo fascinante de las solicitudes de incorporación de cambios es que muestran los comentarios junto a las confirmaciones a las que hacen referencia, por lo que plantear preguntas sobre conjuntos de cambios concretos resulta muy fácil.
Bill recibe la solicitud de incorporación de cambios
.svg?cdnVersion=2441)
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. Él y Mary mantienen un breve intercambio de opiniones a través de la solicitud de incorporación de cambios.
Mary aplica los cambios
.svg?cdnVersion=2441)
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
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 main
git pull
git pull origin marys-feature
git pushEste 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 prefieres los historiales lineales, la función se puede fusionar mediante cambio de base en el extremo de la rama main antes de ejecutar la fusión, lo que provocará una fusión con avance rápido.
Algunas interfaces de usuario automatizan 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 cerrar la solicitud de incorporación de cambios automáticamente cuando la rama de función se fusione en la rama main.
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 y hacer un seguimiento de las ramas que se centran en los conjuntos de funciones del dominio empresarial. Otros flujos de trabajo de Git, como el flujo de trabajo de bifurcación de Git y el flujo de trabajo de Gitflow, se centran en los repositorios y pueden aprovechar el flujo de trabajo de la rama de función de Git para gestionar sus modelos de ramificación. Este documento muestra un ejemplo de código de alto nivel y un ejemplo ficticio para implementar el flujo de trabajo de ramas de función en Git.Algunas de las principales asociaciones que se pueden 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.
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.
Blog de Bitbucket
Ruta de aprendizaje de DevOps
