¿Uso de una twig de desarrollo de larga duración con Git?

Una pregunta relacionada con las buenas prácticas para administrar un proyecto grande con Git: escuché que es una práctica común tener una sucursal de develop , donde se desarrolla, para mantener la twig master solo para versiones estables / de producción. Mi pregunta es: ¿por qué es esto necesario? No estoy pidiendo opiniones / debates, sino los pros y contras de tal técnica.

El problema para mí es que mezcla dos conceptos: sistema de versión y sistema de lanzamiento. Cuando tenga una versión estable / de producción, debe marcarla con una label: esta sería una versión. Cualquier otra cosa obviamente está en desarrollo.

Es aún less claro para mí, ya que es una práctica común tener twigs de feature . Una vez que su twig de feature es estable, ¿cuál es el punto de fusionarla en una twig de develop , en lugar de en la twig master directamente? De nuevo, en mi opinión, solo las tags deberían usarse para mostrar versiones estables, no una twig específica. Entonces, para mí sería correcto tener un código inestable en el master , luego de una fusión con una twig de feature .

Añadiría que en GitHub, el mecanismo de lanzamiento se basa en tags , no se basa en acciones push en una twig específica; para mí, esto es nuevamente un punto en contra del uso de una twig de develop .

La necesidad es cuando tienes una versión de borde sangrante. La logica es como sigue:

  • El maestro siempre tiene un código estable que contiene nuevas características estables que no están presentes en la última versión estable pero que son adecuadas para su uso en entornos de desarrollo.
  • Las tags muestran un hito, una versión estable list para producción
  • La twig de desarrollo contiene funciones con errores en desarrollo activo y no es adecuada para su uso en entornos de desarrollo