Cómo elegir el flujo de trabajo de Git y el modelo de ramificación adecuado para su equipo

Git es el sistema de control de versiones en el corazón de casi todo el desarrollo de software: se utiliza para almacenar y realizar un seguimiento de los cambios en el código que escribe. Cuando se trabaja en equipo, tener un flujo de trabajo fluido que funcione para su empresa es fundamental para crecer rápidamente.

Mejor organización del repositorio, desarrollo más rápido

Con la llegada de canalizaciones de automatización fáciles de usar como Jenkins, muchas empresas están comenzando a implementar la integración y entrega continuas (CI/CD), y los cambios de los desarrolladores a menudo se fusionan en un repositorio, normalmente entregando el producto semanalmente en lugar de semanalmente. horario mensual.

Esta velocidad ejerce mucha presión sobre su organización, especialmente cuando se trata de Git. Si tiene 50 personas que intentan realizar cambios en la misma  master rama, tendrá problemas con frecuentes conflictos de combinación.

Afortunadamente, Git brinda la capacidad de crear ramas y elegir cuándo desea fusionar el código, que cada equipo debe usar para organizar su desarrollo. Tomar el control de su flujo de trabajo de Git al menos evitará que usted y sus compañeros de equipo pierdan el tiempo buscando en Google nuevos problemas de Git.

Características y desarrollo de las ramas.

Hay dos grandes problemas en los que están trabajando las sucursales de Git: mantener tus comandos internos sincronizados y mantener tu lanzamiento público.

Cuando inicie una rama en Git, se realizarán nuevas confirmaciones en esa rama, no en master. Esto puede ser útil para realizar un seguimiento del progreso individual en una función determinada o corregir errores; por ejemplo, cada sucursal puede implementar una característica descrita en un problema en un servicio Kanban como Jira, Trello o Github Issues & Projects.

La fusión de ramas generalmente se realiza mediante solicitudes de extracción, una característica de las soluciones alojadas de Git como Github donde el comando solicita una master extracción de feature una rama e integra los cambios para todos. Esto puede ser muy útil para los equipos que realizan pruebas de control de calidad y unidades para asegurarse de que una sucursal funcione correctamente antes de avanzar en la cadena.

Otro problema es administrar sus lanzamientos: no desea enviar a sus clientes una copia de su última compilación de desarrollo interno, ya que podría corromperse por una mala confirmación.

Para resolver este problema, muchos equipos usarán una rama separada para los lanzamientos y fusionarán esa rama solo cuando sea el momento de lanzar una nueva versión. Esto permite varias confirmaciones en segundo plano en la rama de desarrollo entre versiones.

Otro beneficio de este modelo es la capacidad de realizar confirmaciones separadas en la rama de producción, lo que posiblemente brinde soluciones a los problemas antes de que esté lista la próxima versión.

desarrollo principal

Su estrategia de ramificación determina exactamente cómo utilizará las herramientas que se le proporcionan. Hay muchas estrategias de bifurcación diferentes diseñadas para diferentes tipos de equipos.

El desarrollo basado en autopistas se acerca a lo que debería ser la programación en equipo: iteración rápida en una master sucursal para lanzar rápidamente un producto viable. El equipo crea ramificaciones de funciones de corta duración, que generalmente no duran más de unos pocos días, y a menudo se comprometen directamente con master.

Se llama «tronco» porque master hace que la rama sea la rama más activa y útil de todo el repositorio, como un grueso tronco de árbol que soporta todo lo demás. Todo el desarrollo se centra en esta rama, que es fácil y rápida de aprender, proporcionando una buena experiencia de desarrollador.

Una vez que está listo para el lanzamiento, se crea una nueva rama versionada para cada lanzamiento. Esto separa las versiones mastery también lo ayuda a agregar o seleccionar correcciones para las versiones LTS.

Esto tiene muchas ventajas, especialmente para equipos pequeños. Si trabaja con algunos desarrolladores senior que conoce y confía en los permisos de escritura de todo el repositorio, integrar sus cambios lo antes posible realmente puede acelerar el desarrollo. Al final, esto elimina casi toda la burocracia asociada con las constantes solicitudes de extracción y fusiones, aunque aún es necesaria una comunicación simple con su equipo para mantenerse al tanto y siempre debe saber en qué está trabajando el otro.

Sin embargo, esta no es una buena organización ya que depende de la disciplina y buenos desarrolladores. Esto es realmente genial para lanzar productos rápidamente o iterar rápidamente en proyectos existentes, pero tan pronto como agrega más desarrolladores junior al proyecto u obtiene más colaboradores de código abierto, comienza a mostrar sus fallas.

Flujo de Git tradicional

«Git Flow» es un flujo de trabajo que funciona en muchos equipos. Esto es más complejo que el simple flujo de trabajo de desarrollo de backbone, pero ofrece muchos beneficios para proyectos de código abierto y proyectos grandes con muchos miembros del equipo.

En la estrategia de bifurcación de Git Flow, las bifurcaciones de características duran más y son el foco principal de la integración diaria. Los equipos trabajarán en las funciones hasta que estén listas para la producción y luego pasarán por un proceso de solicitud de extracción para obtener su aprobación. Puede haber cualquier cantidad de características al mismo tiempo, incluidas aquellas que duran lo suficiente como para que se deban volver a basar en master confirmaciones más recientes.

Con Git Flow, el acceso es más limitado, ya que la mayoría de los desarrolladores no tendrán permiso para fusionarse directamente con develop, y ciertamente no con master, y tendrán que crear ramas como método principal para realizar cambios.

Git Flow, naturalmente, deja tiempo para la revisión adecuada del código durante el proceso de solicitud de incorporación de cambios. Esto permite que los conflictos se manejen con PR, rebases y fusiones en lugar de una rama principal que cambia constantemente. Esto tiene sentido para el código abierto porque estas bifurcaciones pueden provenir de terceros, pero también tiene sentido en entornos de equipos grandes o para equipos que desarrollan productos monolíticos con muchos componentes.

Una de las características clave de este flujo de trabajo es la plantilla de lanzamiento. Cuando llega el momento de una nueva versión, se crea una rama separada para la preparación. Las correcciones de errores y los parches finales se realizan aquí, luego se insertan en la master rama real y se les asigna una etiqueta a partir de la cual compilar la versión.

La diferencia clave es que esta master rama se mantiene junto con develop. Las confirmaciones de las ramas de lanzamiento se fusionan nuevamente en develop, así como cualquier corrección. Esto siempre hace que develop la rama más reciente desde la que se realizan los lanzamientos cuando sean estables.

Esta separación facilita la gestión de correcciones de errores menores que deben publicarse antes de master fusionarse con las últimas versiones. La rama de lanzamiento funciona de la misma manera que la rama de características, con la ventaja adicional de estar marcada como estable.

Por supuesto, las solicitudes constantes de extracción, reorganización y combinación son un trabajo duro y pueden ser tediosas si intenta ser rápido. Pero al igual que la escritura estática o las pruebas unitarias, al final vale la pena mantener las cosas organizadas y funcionando sin problemas.

Elija lo que es adecuado para usted

Al final, se trata de una buena etiqueta de equipo, y su equipo puede hacerlo bien con un historial de Git que se parece más a una línea que a un diagrama elegante. Si su proyecto es pequeño o es un aficionado en solitario, cumplir con los estrictos estándares de Git puede hacerle más daño que bien.

Pero si tiene problemas con Git, puede probar el desarrollo de backbone o Git Flow. Como mínimo, comprender la organización de su repositorio lo ayudará a mejorar el proceso de integración.