Exploración del flujo de trabajo de rama de características
La idea central del flujo de trabajo de rama de características es que todo el desarrollo de las características debería tener lugar en una rama dedicada, en lugar de la rama principal.
La encapsulación facilita a varios desarrolladores trabajar en una característica determinada sin alterar el código base principal. También significa que la rama principal nunca contendrá código roto, una gran ventaja para los entornos de integración continua.
La encapsulación del desarrollo de características también permite usar solicitudes de incorporación de cambios, que son una manera de iniciar conversaciones sobre una rama. Permiten a otros desarrolladores cerrar sesión en una característica antes de que se integre en el proyecto oficial. Además, si se queda atascado en medio de una característica, puede abrir una solicitud de incorporación de cambios para pedir sugerencias a sus compañeros.
Las solicitudes de incorporación de cambios hacen que sea increíblemente fácil para el equipo comentar el trabajo de los demás. Además, las ramas de características pueden (y deben) insertarse en el repositorio central. Permiten compartir una característica con otros desarrolladores sin necesidad de tocar el código oficial.
Puesto que la rama principal es la única rama "especial", el almacenamiento de varias ramas de características en el repositorio central no plantea ningún problema. También es una manera cómoda de hacer una copia de seguridad de todas las confirmaciones locales.
Flujo de trabajo de rama de versión
Además del flujo de trabajo de rama de características, otra estrategia usada habitualmente en los flujos de trabajo de bifurcación de Git es la estrategia de rama de versión. Esta estrategia implica la creación de ramas dedicadas específicamente para preparar versiones. La rama de versión se crea normalmente a partir de una rama de características estable, lo que garantiza que solo contiene código probado y validado exhaustivamente. Una vez creada, la rama de versión se somete a pruebas adicionales, correcciones de errores y esfuerzos de estabilización para preparar el código base para la implementación. La rama de versión permite el aislamiento de las actividades relacionadas con la versión del desarrollo de características en curso, lo que proporciona un entorno controlado para finalizar y pulir la próxima versión. Una vez realizadas todas las comprobaciones y ajustes necesarios en la rama de versión, se combina en la rama principal o se implementa directamente en producción, en función del proceso de lanzamiento del equipo. La estrategia de rama de versión ayuda a los equipos a administrar las complejidades de la coordinación de las actividades de lanzamiento mientras se mantiene una rama principal estable para el desarrollo continuo.
Flujo de trabajo de desarrollo troncal
El flujo de trabajo de desarrollo troncal presupone un repositorio central y la rama principal representa el historial oficial del proyecto. En lugar de confirmar directamente en su rama principal local, los desarrolladores crean una rama cada vez que empiezan a trabajar en una nueva característica. Las ramas de características deben tener nombres descriptivos, como nuevas-imágenes-báner o error-91. La idea es dar un propósito claro y muy centrado a cada rama.
Git no hace ninguna distinción técnica entre la rama principal y las ramas de características, por lo que los desarrolladores pueden editar, agregar al "stage" y confirmar los cambios en una rama de características.
Crear una rama
Cuando trabaje en un proyecto, tendrá muchas características o ideas diferentes en curso en un momento dado, algunas de las cuales están listas para usarse y otras no. La bifurcación existe para ayudarle a administrar este flujo de trabajo. Al crear una rama en el proyecto, se crea un entorno en el que probar nuevas ideas.
Además de crear ramas para nuevas características o correcciones, los equipos que siguen un flujo de trabajo de rama de versión también crean ramas dedicadas específicamente para preparar versiones. Estas ramas de versión se derivan normalmente de ramas de características estables para asegurarse de que contienen código probado y validado exhaustivamente. Una vez creada, la rama de versión se somete a pruebas adicionales, correcciones de errores y esfuerzos de estabilización para preparar el código base para la implementación.
Adición de confirmaciones
Una vez que se ha creado la rama, es el momento de empezar a realizar cambios. Cada vez que agrega, edita o elimina un archivo, realiza una confirmación y la agrega a la rama.
Al agregar confirmaciones, se mantiene un seguimiento del progreso mientras se trabaja en una rama de características.
Las confirmaciones también crean un historial transparente del trabajo que otros usuarios pueden seguir para comprender lo que ha hecho y por qué.
Cada confirmación tiene un mensaje de confirmación asociado, en el que se explica por qué se realizó un cambio determinado.
Además, cada confirmación se considera una unidad de cambio independiente. Le permite revertir los cambios si se encuentra un error o si decide tomar una dirección diferente.
Los mensajes de confirmación son esenciales, sobre todo porque Git lleva un seguimiento de los cambios y los muestra como confirmaciones una vez que se han insertado en el servidor.
Si escribe mensajes de confirmación claros, puede facilitar que otras personas sigan el proceso y aporten comentarios.
Apertura de una solicitud de incorporación de cambios
Las solicitudes de incorporación de cambios inician una conversación sobre las confirmaciones. Dado que están estrechamente integradas con el repositorio de Git subyacente, cualquier persona puede ver exactamente qué cambios se combinarían si aceptara la solicitud.
Puede abrir una solicitud de incorporación de cambios en cualquier momento durante el proceso de desarrollo si:
- Apenas tiene código, pero quiere compartir algunas capturas de pantalla o ideas generales.
- Está atascado y necesita ayuda o consejos.
- Está listo para que alguien revise su trabajo.
Con el sistema @mention en el mensaje de la solicitud de incorporación de cambios, puede solicitar comentarios de personas o equipos específicos, tanto si se encuentran en la sala de al lado como a 10 zonas horarias.
Las solicitudes de incorporación de cambios ayudan a contribuir a los proyectos y a administrar los cambios en repositorios compartidos.
Si usa un modelo de bifurcación e incorporación de cambios, las solicitudes de cambios proporcionan una manera de notificar a los encargados de mantenimiento del proyecto los cambios que quiere que tengan en cuenta.
Si usa un modelo de repositorio compartido, las solicitudes de incorporación de cambios ayudan a iniciar la revisión del código y la conversación sobre los cambios propuestos antes de que se combinen en la rama principal.
Análisis y revisión del código
Una vez que se ha abierto una solicitud de incorporación de cambios, la persona o el equipo que revisan los cambios pueden tener preguntas o comentarios.
Quizás el estilo de creación de código no coincida con las directrices del proyecto, falten pruebas unitarias sobre el cambio o todo sea excelente y las propiedades estén en orden.
Las solicitudes de incorporación de cambios están diseñadas para fomentar y atraer este tipo de conversación.
También puede seguir insertando en la rama, teniendo en cuenta la conversación y los comentarios sobre las confirmaciones.
Imagine que alguien comenta que olvidó hacer algo o que hay un error en el código; en este caso, puede corregirlo en la rama e insertar el cambio.
Git mostrará las nuevas confirmaciones y cualquier otro comentario que reciba en la vista unificada de solicitud de incorporación de cambios.
Los comentarios de solicitud de incorporación de cambios se escriben en Markdown, por lo que puede insertar imágenes y emojis, usar bloques de texto con un formato previo y otro formato ligero.
Implementación
Con Git, puede realizar una implementación desde una rama para llevar a cabo las pruebas finales en un entorno antes de proceder a la combinación con la rama principal.
Una vez que se ha revisado la solicitud de incorporación de cambios y la rama supera las pruebas, puede implementar los cambios para comprobarlos. Si la rama causa problemas, puede revertirla implementando la rama principal existente.
Fusionar mediante combinación
Una vez que se han comprobado los cambios, es el momento de combinar el código en la rama principal.
Una vez combinadas, las solicitudes de incorporación de cambios conservan un registro de los cambios históricos en el código. Dado que se pueden realizar búsquedas en ellas, permiten a cualquier persona volver atrás en el tiempo para comprender por qué y cómo se tomó una decisión.
Una manera de asociar problemas con el código es incorporar palabras clave específicas en el texto de la solicitud de incorporación de cambios. Cuando se combina la solicitud de incorporación de cambios, también se pueden cerrar los problemas relacionados.
Este flujo de trabajo ayuda a organizar las ramas que se centran en los conjuntos de características del dominio empresarial y a llevar un seguimiento de ellas.
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 el repositorio y pueden usar el flujo de trabajo de rama de características de Git para administrar sus modelos de bifurcación.