Primero, algunos antecedentes, estamos en el proceso de mover a todos nuestros equipos de proyecto a usar git y estamos en el proceso de establecer las pautas sobre cómo deben organizarse los repositorios para que ciertas sucursales también puedan ser monitoreadas para una integración continua y Despliegue automático a los servidores de prueba. Actualmente hay dos modelos que se están desarrollando:
Fuertemente influenciado por el artículo de nvie.com sobre la ramificación exitosa con la rama maestra que representa el código más estable, una rama de desarrollo para el código de última generación y una rama de integración para el código que está listo para la prueba de control de calidad.
Un modelo alternativo en el que la rama maestra representa el código de desarrollo de última generación, una rama de integración para el código que está listo para las pruebas de control de calidad y una rama de producción para el código estable que está listo para la implementación.
En este punto, es en parte una cuestión de semántica con respecto a lo que representa la rama maestra, pero ¿es realmente una buena práctica hacer un desarrollo activo en la rama maestra o no es realmente tan relevante?
Respuestas:
La única característica definitoria real de la
masterrama es que es el valor predeterminado para algunas operaciones. Además, los nombres de las ramas solo tienen significado dentro de un repositorio específico. Mimasterpoder señala a sudevelopment, por ejemplo. Además,masterni siquiera se requiere una rama, por lo que si hay alguna confusión sobre qué rama debería ser, mi consejo suele ser dejarla por completo.Sin embargo, en mi opinión, la mejor manera de pensarlo es como el valor predeterminado para presionar. La mayoría de los tutoriales en línea que leen sus desarrolladores van a asumir eso. Por lo tanto, tiene mucho sentido tener
mastercualquier rama a la que se empuje con más frecuencia. Algunas personas piensan que es una copia inmaculada que no puede ser tocada por los desarrolladores, excepto después del más estricto escrutinio, pero usarla de esa manera elimina muchos de los valores predeterminados útiles que proporciona git. Si desea ese tipo de rama prístina, lo pondría en un repositorio completamente separado en el que solo algunas personas pueden escribir.fuente
No, no es aconsejable, incluso al principio, antes de pasar al control de calidad. Como práctica recomendada, el patrón de desarrollo debe ser coherente de principio a fin. Su rama maestra debe comenzar vacía, debe ramificar su rama de desarrollo y comenzar a agregar archivos, fusionarse en su rama de integración, y luego a su maestro.
Si bien a nadie puede importarle durante el desarrollo que la rama maestra no construya, se presta a los malos hábitos desde el principio. El maestro siempre debe compilar, y para lanzamientos de funciones principales tampoco sería una mala idea tener ramas archivadas de compilaciones principales para que se puedan volver a los puntos de lanzamiento estables si es necesario.
fuente