La idea central detrás del Feature Branch Workflow es que todo el desarrollo de la característica debe tener lugar en una rama dedicada en lugar de la rama master. Esta encapsulación facilita que varios desarrolladores trabajen en una característica particular sin perturbar el código base principal. También significa que la rama master nunca contendrá código roto, lo cual es una gran ventaja para los entornos de integración continua.
Encapsular el desarrollo de características también hace posible aprovechar las solicitudes de extracción, que son una forma de iniciar discusiones en torno a una rama. Dan a otros desarrolladores la oportunidad de aprobar una característica antes de que se integre en el proyecto oficial. O, si te quedas atascado en medio de una función, puedes abrir una solicitud de extracción para pedir sugerencias a tus colegas. La cuestión es que los pull requests hacen que sea increíblemente fácil para tu equipo comentar el trabajo de los demás.
El flujo de trabajo Git Feature Branch es un flujo de trabajo componible que puede ser aprovechado por otros flujos de trabajo Git de alto nivel. Hablamos de otros flujos de trabajo Git en la página de resumen de flujos de trabajo Git. El flujo de trabajo Git Feature Branch se centra en el modelo de ramificación, lo que significa que es un marco de referencia para la gestión y creación de ramas. Otros flujos de trabajo están más centrados en los repositorios. El flujo de trabajo Git Feature Branch puede incorporarse a otros flujos de trabajo. Los flujos de trabajo Gitflow y Git Forking utilizan tradicionalmente un flujo de trabajo Git Feature Branch en lo que respecta a sus modelos de ramificación.
Cómo funciona
El flujo de trabajo Feature Branch asume un repositorio central, y master representa la historia oficial del proyecto. En lugar de confirmar directamente en su rama local master, los desarrolladores crean una nueva rama cada vez que comienzan a trabajar en una nueva característica. Las ramas de características deben tener nombres descriptivos, como animated-menu-items o issue-#1061. La idea es dar un propósito claro y muy enfocado a cada rama. Git no hace ninguna distinción técnica entre la rama master y las ramas de características, por lo que los desarrolladores pueden editar, poner en escena y confirmar los cambios en una rama de características.
Además, las ramas de características pueden (y deben) ser empujadas al repositorio central. Esto hace posible compartir una característica con otros desarrolladores sin tocar ningún código oficial. Dado que master es la única rama «especial», almacenar varias ramas de características en el repositorio central no plantea ningún problema. Por supuesto, esta es también una forma conveniente de respaldar los commits locales de todos. Lo siguiente es un paseo por el ciclo de vida de una rama de características.
Empieza con la rama maestra
Todas las ramas de características se crean a partir del último estado del código de un proyecto. Esta guía asume que éste se mantiene y actualiza en la rama master.
git checkout master
git fetch origin
git reset --hard origin/masterEsto cambia el repo a la rama master, saca los últimos commits y restablece la copia local del repo de master para que coincida con la última versión.
Crear una nueva rama
Usa una rama distinta para cada característica o problema en el que trabajes. Después de crear una rama, compruébala localmente para que cualquier cambio que hagas esté en esa rama.
git checkout -b new-featureEsto comprueba una rama llamada new-feature basada en master, y la bandera -b le dice a Git que cree la rama si no existe ya.
Actualiza, añade, confirma y empuja los cambios
En esta rama, edita, prepara y confirma los cambios de la manera habitual, construyendo la característica con tantos commits como sea necesario. Trabaja en la función y haz commits como lo harías cada vez que uses Git. Cuando esté listo, empuja tus commits, actualizando la rama de la función en Bitbucket.
git status
git add <some-file>
git commitEmpujar la rama de la función a la remota
Es una buena idea empujar la rama de la función al repositorio central. Esto sirve como una copia de seguridad conveniente, cuando se colabora con otros desarrolladores, esto les daría acceso a ver los commits de la nueva rama.
git push -u origin new-featureEste comando empuja new-feature al repositorio central (origen), y la bandera -u lo añade como una rama de seguimiento remoto. Después de configurar la rama de seguimiento, git push se puede invocar sin ningún parámetro para empujar automáticamente la rama de la nueva característica al repositorio central. Para obtener comentarios sobre la nueva rama de características, crea una solicitud de extracción en una solución de gestión de repositorios como Bitbucket Cloud o Bitbucket Server. Desde ahí, puedes añadir revisores y asegurarte de que todo está bien antes de fusionar.
Resolver los comentarios
Ahora los compañeros de equipo comentan y aprueban los commits empujados. Resuelve sus comentarios localmente, haz un commit y empuja los cambios sugeridos a Bitbucket. Tus actualizaciones aparecen en el pull request.
Fusiona tu pull request
Antes de fusionar, puede que tengas que resolver conflictos de fusión si otros han hecho cambios en el repo. Cuando tu pull request esté aprobado y libre de conflictos, puedes añadir tu código a la rama master. Fusiona desde el pull request en Bitbucket.
Pull requests
Además de aislar el desarrollo de características, las ramas hacen posible discutir los cambios a través de pull requests. Una vez que alguien completa una característica, no la fusiona inmediatamente en master. En su lugar, empujan la rama de la característica al servidor central y presentan una solicitud de extracción pidiendo que se fusionen sus adiciones en master. Esto da a otros desarrolladores la oportunidad de revisar los cambios antes de que se conviertan en una parte de la base de código principal.
La revisión del código es un beneficio importante de las solicitudes de extracción, pero en realidad están diseñadas para ser una forma genérica de hablar sobre el código. Puedes pensar en los pull requests como una discusión dedicada a una rama en particular. Esto significa que también se pueden utilizar mucho antes en el proceso de desarrollo. Por ejemplo, si un desarrollador necesita ayuda con una característica particular, todo lo que tiene que hacer es presentar una solicitud de extracción. Las partes interesadas serán notificadas automáticamente, y podrán ver la pregunta justo al lado de los commits relevantes.
Una vez que una solicitud de extracción es aceptada, el acto real de publicar una característica es muy parecido al del flujo de trabajo centralizado. En primer lugar, tienes que asegurarte de que tu master local está sincronizado con el master de subida. A continuación, fusionas la rama de características en master y empujas la master actualizada de vuelta al repositorio central.
Las solicitudes de extracción pueden ser facilitadas por soluciones de gestión de repositorios de productos como Bitbucket Cloud o Bitbucket Server. Consulta la documentación sobre pull requests de Bitbucket Server para ver un ejemplo.
Ejemplo
El siguiente es un ejemplo del tipo de escenario en el que se utiliza un flujo de trabajo de ramificación de características. El escenario es el de un equipo que hace una revisión de código en torno a un pull request de una nueva característica. Este es un ejemplo de los muchos propósitos para los que se puede utilizar este modelo.
María comienza una nueva característica
Antes de comenzar a desarrollar una característica, María necesita una rama aislada en la que trabajar. Puede solicitar una nueva rama con el siguiente comando:
git checkout -b marys-feature masterEsto comprueba una rama llamada marys-feature basada en master, y la bandera -b indica a Git que cree la rama si no existe ya. En esta rama, María edita, escenifica y confirma los cambios de la manera habitual, construyendo su característica con tantos commits como sea necesario:
git status
git add <some-file>
git commitMaría se va a comer
.svg?cdnVersion=1520)
María añade unos cuantos commits a su característica a lo largo de la mañana. Antes de que se vaya a comer, es una buena idea empujar su rama de características al repositorio central. Esto sirve como una copia de seguridad conveniente, pero si María estaba colaborando con otros desarrolladores, esto también les daría acceso a sus confirmaciones iniciales.
git push -u origin marys-featureEste comando empuja marys-feature al repositorio central (origen), y la bandera -u lo añade como una rama de seguimiento remoto. Después de configurar la rama de seguimiento, María puede llamar a git push sin ningún parámetro para empujar su característica.
María termina su característica
Cuando María vuelve de comer, completa su feature. Antes de fusionarla con master, necesita presentar un pull request para que el resto del equipo sepa que ha terminado. Pero primero, debe asegurarse de que el repositorio central tiene sus commits más recientes:
git pushEntonces, presenta el pull request en su Git GUI pidiendo fusionar marys-feature en master, y los miembros del equipo serán notificados automáticamente. Lo mejor de los pull requests es que muestran comentarios justo al lado de sus commits relacionados, por lo que es fácil hacer preguntas sobre conjuntos de cambios específicos.
Bill recibe el pull request
.svg?cdnVersion=1520)
Bill recibe el pull request y le echa un vistazo a marys-feature. Decide que quiere hacer algunos cambios antes de integrarlo en el proyecto oficial, y él y Mary tienen algunas idas y venidas a través del pull request.
Mary hace los cambios
.svg?cdnVersion=1520)
Para hacer los cambios, María utiliza exactamente el mismo proceso que hizo para crear la primera iteración de su característica. Ella edita, etapas, confirma, y empuja las actualizaciones al repositorio central. Toda su actividad se muestra en el pull request, y Bill puede seguir haciendo comentarios a lo largo del camino.
Si quisiera, Bill podría sacar marys-feature en su repositorio local y trabajar en él por su cuenta. Cualquier commit que añadiera también aparecería en el pull request.
Mary publica su característica
Una vez que Bill está listo para aceptar el pull request, alguien tiene que fusionar la característica en el proyecto estable (esto puede hacerlo tanto Bill como Mary):
git checkout master
git pull
git pull origin marys-feature
git pushEste proceso a menudo resulta en un merge commit. A algunos desarrolladores les gusta esto porque es como una unión simbólica de la característica con el resto de la base de código. Pero, si eres partidario de una historia lineal, es posible volver a basar la característica en la punta de master antes de ejecutar la fusión, lo que resulta en una fusión de avance rápido.
Algunas interfaces gráficas de usuario automatizarán el proceso de aceptación de la solicitud de extracción mediante la ejecución de todos estos comandos con sólo hacer clic en un botón «Aceptar». Si la suya no lo hace, al menos debería ser capaz de cerrar automáticamente el pull request cuando la rama de la característica se fusiona en master.
Mientras tanto, John está haciendo exactamente lo mismo
Mientras Mary y Bill están trabajando en marys-feature y discutiéndolo en su pull request, John está haciendo exactamente lo mismo con su propia rama de la característica. Aislando las características en ramas separadas, todo el mundo puede trabajar de forma independiente, pero sigue siendo trivial compartir los cambios con otros desarrolladores cuando sea necesario.
Resumen
En este documento, hemos hablado del flujo de trabajo de la rama de características de Git. Este flujo de trabajo ayuda a organizar y hacer un seguimiento de las ramas que se centran en los conjuntos de características 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 bifurcación de características de Git para gestionar sus modelos de bifurcación. Este documento muestra un ejemplo de código de alto nivel y un ejemplo ficticio para implementar el flujo de trabajo de bifurcación de características de Git. Algunas asociaciones clave para hacer con el flujo de trabajo de la rama de características son:
- enfocado en los patrones de ramificación
- puede ser aprovechado por otros flujos de trabajo orientados a los repositorios
- promueve la colaboración con los miembros del equipo a través de las solicitudes de extracción y las revisiones de fusión
Utilizar git rebase durante las etapas de revisión y fusión de una rama de características creará reforzar un historial Git cohesivo de fusiones de características. Un modelo de bifurcación de características es una gran herramienta para promover la colaboración dentro de un entorno de equipo.
Adéntrate un poco más en los flujos de trabajo de Git leyendo nuestro completo tutorial del flujo de trabajo Gitflow.