Han pasado dos años desde la última respuesta a esta pregunta y creo que ahora la historia cambia. Para mí, la respuesta es "Siempre que use el control del código fuente para rastrear versiones".
Para elaborar, en estos días el seguimiento de versiones de proyectos con control de código fuente no siempre funciona. (por ejemplo, usando npm para gestionar la dependencia y especificar versiones semánticas con '^') En ese caso, los artefactos del proyecto cambian cada vez que se produce una compilación, sin corresponder necesariamente a los cambios del código fuente cada vez. Para manejar este tipo de nuevos desafíos, algunos equipos eligen haber construido 'artefactos' guardados en el sistema de control de artefactos (por ejemplo, JFrog Artifactory) para realizar un seguimiento de las versiones del proyecto.
Obviamente, cuando ya tiene el control de versión de artefactos en su lugar, no extraerá el 'código de producción' de una rama GIT y lo compilará / implementará en producción, en su lugar, consultará al sistema de control de artefactos para obtener versiones directamente ejecutables para la implementación. En tales casos, el concepto de 'rama de liberación' pierde repentinamente su significado. Y cada vez que su equipo decida no asociar git branch con la versión de lanzamiento, comprometerse / presionar directamente para dominar se convierte en una buena opción una vez más: viene como rama predeterminada cada vez que se clona el repositorio, por lo tanto, dada la semántica ampliamente aceptada y bien comunicada cambios Aún así, como sugiere la respuesta aceptada, probablemente deberías ir a asignar un rol a las ramas, incluido el maestro, y usar esas ramas solo para esos roles en particular.
Por último, voy un paso más allá y sugiero usar master como rama de desarrollo en proyectos con solo un puñado de committers principales. Cuál es el caso de mi equipo y probablemente lo mismo para la mayoría de las tiendas de microservicios. Comprometerse con master elimina la comunicación del proceso de cambios y potencialmente evita 'fusionar el infierno' cuando se trabaja en funciones en múltiples sprints. Además, el código en la rama maestra ni siquiera tiene que 'funcionar', el proceso automatizado de compilación / prueba le dirá qué salió mal y de todos modos es bastante fácil verificar el historial de git y contactar al autor que rompió la compilación / prueba :-)