Tres enfoques
Puede utilizar una de estas técnicas populares o puede utilizarlas como base para crear las suyas propias.
Flujo de GitHub . La estrategia es utilizada por el equipo de servicio de GitHub. Los principales requisitos son los siguientes:
- No hay errores en el código de la rama maestra y debe estar lista para implementarse en cualquier momento;
- para comenzar a desarrollar una nueva función, debe crear una rama de función en la rama maestra y darle un nombre que sea obvio para todos. Cuando el trabajo está listo, debe fusionarse en la rama maestra mediante una solicitud de extracción;
- después de fusionar los cambios, debe implementarlos inmediatamente en el servidor.
Este enfoque se suele utilizar para productos con una única versión que no se actualiza con mucha frecuencia. Por ejemplo, sitios web. En el lado positivo, este enfoque facilita que los desarrolladores comprendan y organicen su trabajo. La principal desventaja es que si su proyecto es lo suficientemente complejo y se actualiza con frecuencia, es mejor utilizar una estrategia diferente.
GitFlow . Cabe decir de inmediato que esta estrategia es discutible. Hay muchas críticas tanto positivas como negativas sobre ella.
La conclusión es la siguiente. Hay dos tipos de ramas persistentes: la rama maestra, para comprender cómo se ve la última versión actual, y la rama de desarrollo, donde se está desarrollando. Hay tres tipos de ramas temporales a partir de él.
- Característica, para agregar nuevas características. Después de completar el trabajo, debe crear una solicitud de extracción en la rama de desarrollo.
- Suelte para trabajar en nuevas versiones. Es importante agregar el número de versión al título, esto lo ayudará a evitar confusiones y realizar un seguimiento de los cambios.
- Hotfix, para corregir errores rápidamente.
Este enfoque se considera uno de los mejores para proyectos en los que se desarrollan constantemente varias versiones para diferentes plataformas.
En 2010, se publicó el texto del programador holandés Vincent Driessen " Un modelo de ramificación Git exitoso ", en el que habló por primera vez sobre GitFlow. El artículo se hizo bastante popular, apareció una traducción al ruso y el método fue adoptado por muchos equipos.
En 2020, el programador estadounidense George Stoker publicó un artículo “ Por favor, deje de recomendar Git Flow", Donde criticó el método como anticuado e ineficaz en las realidades modernas. Driessen, en respuesta, complementó su texto de 2010 con un descargo de responsabilidad, en el que admitió que su método no era una panacea, sino solo una de las opciones para organizar el trabajo.
Flujo de trabajo de bifurcación. Aquí el enfoque es el siguiente: hay un repositorio original para fusionar todos los cambios y una copia del mismo, en el que trabaja otro desarrollador. El enfoque está muy cerca de la ideología del código abierto, su objetivo es utilizar todas las ventajas de la comunidad de código abierto dentro del proyecto. Sin embargo, la mayor parte del flujo de trabajo de ramificación copia GitFlow. Las ramas de características aquí se fusionarán con los repositorios de desarrolladores locales. Por lo tanto, el desarrollo se vuelve flexible incluso para equipos muy grandes con contratistas.
Entre los que adoptan este enfoque se encuentra Linux . Puede ofrecer sus propias opciones para cambiar el código incluso para el núcleo del sistema. Y este enfoque parece funcionar de manera eficaz.
Puntos generales
Cualquiera que sea el concepto que elija, hay puntos básicos a los que es mejor atenerse. Por ejemplo, estas son las reglas de Microsoft :
- no complique demasiado la estrategia de su sucursal;
- use ramas de funciones para todas las actualizaciones y correcciones de errores;
- fusionar ramas de características en ramas principales mediante solicitudes de extracción;
- Mantenga la calidad upstream y actualizada.
Una estrategia basada en estas ideas llevará a su equipo a trabajar con versiones lógicas y fáciles de entender.
Aquí hay algunas pautas más útiles.
Llámalo simple y obvio
Esto ayudará a todos los miembros del equipo a comprender correctamente quién está trabajando en qué. También es aceptable incluir información adicional en el nombre de la rama, por ejemplo, el nombre del creador. Este es el caso cuando no necesita crear algo original. Lo que necesita son nombres de sucursales como "usuarios", "corrección de errores", "función", "revisión". Para las ramas que están retrasadas, use indicadores especiales separados. Esto permitirá que el equipo comprenda de inmediato lo que está en juego y siempre tenga en cuenta estas tareas a largo plazo.
Fusionar ramas solo a través de una solicitud de extracción
El mecanismo de solicitud de extracción ha demostrado ser lógico y bien pensado. Dado que este proceso lleva tiempo, debe acordar dentro del equipo qué y en qué plazo se espera de todos los participantes en la solicitud de extracción. Asigne las responsabilidades de los revisores y compártalas con el equipo a través de la base de conocimientos interna.
A continuación, se ofrecen algunos consejos específicos:
- según la investigación de Microsoft , el número óptimo de revisores es dos;
- si su equipo ya ha formado los principios de la revisión de código, apéguese a ellos y trate de no romper;
- Una solicitud de extracción funciona mucho mejor cuando más miembros del equipo se encargan regularmente de revisar el código;
- Deje descripciones de su trabajo con suficiente detalle para que los revisores puedan comprender rápidamente el contexto.
Configurar políticas de sucursales
Vale la pena dedicar tiempo a las políticas de ramificación por varias razones:
- de esta manera puede aislar el trabajo actual del trabajo completado dentro de la rama principal;
- hacer restricciones razonables determinando quién y qué cambios pueden realizar en ramas específicas;
- Difundir rápidamente métodos de trabajo eficaces.
Hay dos reglas básicas según las políticas que se deben configurar:
- los revisores se agregan automáticamente a una solicitud de extracción en el momento de su creación. Primero puede definir una lista de ellos y luego editarlos sobre la marcha;
- Se requiere una compilación exitosa para completar la solicitud de extracción. El código vertido en la rama principal debe compilarse limpiamente.
Pero el principio más importante al crear su estrategia de sucursal es este: debe pensarlo para que el equipo no tenga preguntas sobre el significado de esta o aquella acción. Entonces en tu proyecto todos los días serán productivos.
Blog ITGLOBAL.COM - TI administrada, nubes privadas, IaaS, servicios de seguridad de la información para empresas: