Al usar Git, ¿es aconsejable usar la rama maestra para el desarrollo activo?


32

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:

  1. 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.

  2. 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?


1
Me gusta el worfklow que Scott Chacon usa para desarrollar GitHub: scottchacon.com/2011/08/31/github-flow.html
user16764

1
Según lo descrito, me parece un problema semántico más que nada: cualquier organización va a desarrollar sus propios procesos y, en algunos aspectos, los nombres deben reflejar su flujo de trabajo. Genéricamente, la clave parece ser que en algún lugar usted define algo tal que "el código fuente de HEAD siempre refleje un estado listo para producción". Lo que eliges llamar eso es menos importante, pero tanto git-flow como el flujo de trabajo de GitHub se centran en esa separación y en el control cuando pasas a la "cosita" lista para producción
Murph

@Murph: es cierto, pero dado que estamos haciendo algo de esto desde cero, pensé que sería mejor seguir más o menos las convenciones comunes para que los nuevos desarrolladores contratados no tengan una curva de aprendizaje pronunciada debido a prácticas internas inusuales.
rjzii

Entonces has respondido tu propia pregunta (-: Para ser honesto, incluso al hacer la pregunta estás muy por delante de la curva ...
Murph

Respuestas:


33

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. Mi masterpoder señala a su development, 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.


77
+1. Y debido a que el código "listo para producción" es el código importante, también debe vivir en una rama con un nombre que resalte esta importancia. "maestro" como el nombre de rama predeterminado seguramente no cumple esa solicitud, ya que también se usa en cualquier otro repositorio para cualquier intención.
Bananeweizen

44
+1. Esta es la respuesta de la vida real. Para enfatizar el punto: nadie en su equipo definió la rama "maestra", lo hizo el sistema git. Para cualquier cosa importante, adhiérase a las ramas que alguien en su equipo ha definido.
Travis Wilson

1
Completamente de acuerdo. Si bien me gusta mucho el modelo de flujo de git ( nvie.com/posts/a-successful-git-branching-model ), lo único que me perturba es que master está estrictamente reservado para lanzamientos, lo que es contraintuitivo.
Bachi

12

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.


3
¿No es mejor hacer un seguimiento de la versión a través de etiquetas?
Adonis K. Kakoulidis

1
@AdonisK .: No veo la relevancia de su pregunta.
Joel Etherton
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.