¿Utiliza este o un flujo de trabajo de ramificación git similar?
Utilizamos un flujo de trabajo similar en el trabajo, pero un poco menos complicado. Sin embargo, está muy inspirado en este flujo de trabajo, ya que he leído este artículo muchas veces. Incluso tengo el pdf del modelo de ramificación impreso en colores al lado de mi escritorio :)
¿Considera que este es un enfoque productivo?
Productivo. ¿Cómo define usted la productividad? Bueno, en mi opinión, lo más importante es tener alta calidad, al menos para tratar de lograr una mejor calidad todo el tiempo. Mejorar constantemente el proceso, etc. Si puede producir código de calidad, la productividad se beneficiará de él. Entonces la pregunta es realmente: ¿Mejora esto la calidad del software? Y mi respuesta a eso es definitivamente sí.
Lo que más me gusta de este tipo de modelo de ramificación es que introduce sucursales en diferentes capas de calidad. Cuanto más a la derecha en la imagen, mayor estabilidad y mayor calidad. La rama maestra es sagrada y todos los compromisos deben considerarse como versiones estables del software. Cuanto más a la izquierda vaya, más experimental y más baja será la estabilidad.
Tan pronto como pruebe las nuevas características y las correcciones de errores, puede transferirlas gradualmente de izquierda a derecha y, por lo tanto, mover el código con alta calidad exactamente cuando sepa que el código cumple con los requisitos de calidad que exige del código. Bueno, al menos en teoría, ya que no puede probar todo al 100% y saber con certeza que el código no contiene ningún error, porque siempre tendrá errores. Pero le permite mantener una gran confianza.
Como programador, nada apesta más que trabajar en un sistema en el que nadie confía en el código, porque saben que simplemente apesta y que hay un montón de errores en él.
¿Ves alguna falla con este enfoque? ¿Alguna desventaja potencial?
Es importante pensar en su modelo de ramificación para que se ajuste bien a las necesidades de su organización. El hecho de que este modelo funcione bien para algunas personas no significa necesariamente que sea óptimo o deseable para otra.
Siempre hay compensaciones e incluso en este caso. Una compensación es el número de sucursales versus la complejidad. Al introducir muchos tipos diferentes de ramas, aumenta la complejidad del flujo de trabajo. Por ejemplo, podría ser simplemente incorrecto obligar siempre a las personas a crear una nueva rama de características, cuando intentan corregir un error simple cambiando un par de líneas de código.
Todos sabemos que los errores son más o menos complicados de resolver. Entonces, cuando se descubre un error trivial, es posible que desee reducir la complejidad y la administración para deshacerse de la sobrecarga adicional y simplemente dejar que las personas se comprometan directamente, por ejemplo, con la rama maestra o de desarrollo. Pero a medida que la naturaleza de sus arreglos se vuelve más complicada, vale la pena esa sobrecarga adicional para crear nuevas ramas para ellos. Especialmente si no está seguro del tamaño y la longitud del mismo o si desea mejorar la colaboración entre usted y los otros desarrolladores.
Si tiene un mejor enfoque, ¿le importaría compartir o proporcionar un enlace a un artículo o discusión al respecto?
Este es sin duda un buen enfoque y podría encajar en la mayoría de los casos, ya que la mayoría de nosotros tenemos procesos de desarrollo similares, pero podría no ser adecuado para todos. Le recomiendo encarecidamente que piense cómo maneja su código en este momento e intente crear un modelo de ramificación que se ajuste al que ya tiene.
El punto más importante es comenzar con git y el resto seguirá naturalmente. ¡Comience simple y mejore gradualmente! ¡Ser creativo!
Salud