version control - practices - Estrategias de ramificación
success git branch (17)
- Una rama para el desarrollo activo (/ principal o principal, según la jerga)
- Una rama para cada versión de mantenimiento -> recibirá solo correcciones realmente pequeñas, mientras que todo el desarrollo principal va a / main
- Una rama para cada nueva tarea: crea una nueva rama para trabajar en cada nueva entrada en tu Bugzilla / Jira / Rally. Comprometerse a menudo, documentar el cambio por sí mismo utilizando registros de guijarros en pulgadas, y fusionarlo nuevamente a su rama "principal" solo cuando esté terminado y bien probado.
Eche un vistazo a este http://codicesoftware.blogspot.com/2010/03/branching-strategies.html para una mejor explicación
La compañía para la que trabajo está empezando a tener problemas con su modelo de ramificación actual y me preguntaba a qué tipos diferentes de estrategias de ramificación ha estado expuesta la comunidad.
¿Hay algunos buenos para diferentes situaciones? ¿Qué usa tu empresa? ¿Cuáles son las ventajas y desventajas de ellos?
Actualmente contamos con una sucursal para mantenimiento continuo, una rama para "nuevas iniciativas" que simplemente significa "cosas que saldrán en algún momento en el futuro, no estamos seguros de cuándo". También ocasionalmente hemos tenido dos ramas de mantenimiento en marcha: una para proporcionar soluciones para lo que está actualmente en producción y otra que aún está en control de calidad.
La principal ventaja que hemos visto es la capacidad de reaccionar ante las solicitudes de los usuarios y las emergencias con mayor rapidez. Podemos hacer la corrección en la rama que está en producción y liberarla sin liberar nada extra que ya haya sido registrado.
La principal desventaja es que terminamos fusionando muchas ramas, lo que aumenta las posibilidades de que algo se pierda o se fusione incorrectamente. Hasta ahora, eso no ha sido un problema, pero definitivamente es algo a tener en cuenta.
Antes de instituir esta política, generalmente hacíamos todo el desarrollo en el tronco y solo ramificamos cuando lanzamos el código. Luego hicimos arreglos contra esa rama según sea necesario. Era más simple, pero no tan flexible.
El control de versiones de Henrik Kniberg para múltiples equipos ágiles también tiene algunos puntos buenos que tomar en consideración.
Este es el método que he usado en el pasado con buen éxito:
/ tronco - borde sangrante. Siguiente gran lanzamiento del código. Puede o no funcionar en un momento dado.
/branches/1.0, 1.1, etc. Ramas de mantenimiento estable del código. Se usa para corregir errores, estabilizar nuevos lanzamientos. Si es una sucursal de mantenimiento, debe compilar (si corresponde) y estar listo para QA / envío en cualquier momento. Si es una rama de estabilización, debería compilarse y ser una característica completa. No se deben agregar nuevas características, ni refactorizar, ni limpiar el código. Puede agregar un prefijo previo para indicar ramas de estabilización frente a ramas de mantenimiento.
/ branches / cool_feature. Se usa para trabajos altamente experimentales o destructivos que pueden o no convertirse en tronco (o en una rama de mantenimiento). No hay garantías sobre cómo compilar código, trabajar o comportarse de forma sensata. Debe durar el mínimo tiempo posible antes de fusionarse en la rama principal.
/tags/1.0.1, 1.0.2, 1.1.3a, etc. Se utiliza para etiquetar una versión empaquetada y enviada. Nunca cambia NUNCA. Haz tantas etiquetas como quieras, pero son inmutables.
Esto dependerá de qué sistema de control de versiones esté usando. Cada VCS tiene diferentes enfoques para la bifurcación.
¿Qué VSC usas?
Gnat ha escrito este excelente desglose de los diversos consejos que puede encontrar en las estrategias de ramificación.
No hay una estrategia de ramificación, es para lo que funciona:
- El tamaño de tu equipo
- Su producto y los períodos del ciclo de vida
- La tecnología que estás usando (web, incrustada, aplicaciones de Windows)
- Su control de fuente, por ejemplo, Git, TFS, Hg
La post Jeff Atwood analiza muchas posibilidades. Otro para agregar es el concepto de promoción (del enlace de Ryan Duffield). En esta configuración, tiene una rama dev, prueba bracnh y rama de publicación. Promociona su código hasta que llega a la rama de lanzamiento y se implementa.
Jeff Atwood wrote sobre esto en una buena publicación de blog; esa publicación tiene algunos enlaces importantes en ella.
La alternativa que no veo aquí es la filosofía de "Branch on Change".
En lugar de tener su baúl en el "Salvaje Oeste", ¿qué pasa si el baúl es la "Versión actual"? Esto funciona bien cuando solo hay una versión de la aplicación lanzada a la vez, como un sitio web. Cuando se necesita una nueva característica o corrección de errores, se crea una rama para mantener ese cambio. A menudo, esto permite migrar las correcciones para liberarlas individualmente y evita que los codificadores de vaqueros agreguen accidentalmente una función para lanzar que no pretendías. (A menudo es una puerta trasera: "solo para desarrollo / prueba")
Los indicadores de Ben Collins son bastante útiles para determinar qué estilo funcionaría bien para su situación.
La filosofía que seguimos en el trabajo es mantener el tronco en un estado en el que pueda empujar en cualquier momento sin causar daños drásticos al sitio. Esto no quiere decir que el tronco siempre estará en perfecto estado. Por supuesto, habrá errores en él. Pero el punto es nunca, nunca dejarlo roto drásticamente.
Si tiene una característica para agregar, bifurque. Un cambio de diseño, rama. Ha habido tantas veces que pensé: "oh, puedo hacer esto en el maletero, no me tomará tanto tiempo", y luego, 5 horas más tarde, cuando no puedo descifrar el error que está rompiendo las cosas. realmente deseé haberme ramificado.
Cuando mantiene el tronco limpio, permite la oportunidad de aplicar rápidamente y eliminar correcciones de errores. No tiene que preocuparse por el código roto que tiene que se ramificó convenientemente.
Lo primero: KISS (¡Qué simple sea la estupidez!)
/branches /RB-1.0 (*1) /RB-1.1 (*1) /RB-2.0 (*1) /tags /REL-1.0 (or whatever your version look like e.g. 1.0.0.123 *2) /REL-1.1 /REL-2.0 /trunk current development with cool new features ;-)
* 1) Mantener la versión que se puede mantener, por ejemplo, Service Packs, Hotfixes, Bugfixes que pueden fusionarse en trunk si es necesario y / o necesario) * 2) major.minor.build.revision
Reglas del pulgar:
- La carpeta de etiquetas no necesita ser revisada
- Solo unas pocas codificaciones en las ramas de publicación (hace que la fusión sea más simple) - sin limpieza de código, etc.
- Nunca a la codificación en la carpeta de etiquetas
- Nunca coloque información de versión concreta en los archivos fuente. Use Place-holders o 0.0.0.0 que el mecanismo de compilación reemplazará por el número de versión que está construyendo
- Nunca coloque bibliotecas de terceros en su control de código fuente (tampoco nadie agregará bibliotecas STL, MFC, etc. a SVN ;-))
- Solo código de confirmación que compila
- Prefiere usar variables de entorno en lugar de rutas codificadas (rutas absolutas y relativas)
--hfrmobile
No importa qué patrón de ramificación elija, debe tratar de mantener sus ramas en forma de árbol binario de esta manera:
trunk - tags
|
next
/ / /
bugfix f1 f2
/ / /
f11 f21 f22
- Los nodos secundarios solo deben fusionarse con el padre directo.
- Intente lo mejor para fusionar solo la rama completa con la rama padre. nunca combine subcarpetas dentro de una rama.
- Puede seleccionar compromisos cuando sea necesario, siempre y cuando solo se fusionen y seleccionen de una sucursal completa.
- La siguiente rama en la figura de arriba es solo para ilustración, puede que no la necesite.
Nos ramificamos cuando un lanzamiento está listo para el control de calidad final. Si se descubren problemas durante el proceso de control de calidad, los errores se corrigen en la sucursal, se validan y luego se fusionan en el enlace troncal. Una vez que la rama aprueba el control de calidad, lo etiquetamos como un lanzamiento. Las revisiones para esa versión también se realizan en la sucursal, se validan, se fusionan en la troncal y luego se etiquetan como una versión separada.
La estructura de la carpeta se vería así (1 línea de QA, 2 versiones de revisión y el tronco):
/ ramas
/REL-1.0
/ etiquetas
/REL-1.0
/REL-1.0.1
/REL-1.0.2
/el maletero
Nuestro repositorio se ve así:
/trunk
/branches
/sandbox
/vendor
/ccnet
/ trunk es su desarrollo estándar de vanguardia. Usamos CI así que esto siempre debe construir y aprobar pruebas.
/ branches Aquí es donde ponemos grandes cambios ''sancionados'', es decir, algo que SABEMOS lo convertirá en el tronco, pero puede necesitar algún trabajo y romper CI. También donde trabajamos en lanzamientos de mantenimiento, que tienen sus propios proyectos de CI.
/ sandbox cada desarrollador tiene su propia caja de arena, más una zona de pruebas compartida. Esto es para cosas como "vamos a agregar un proveedor de LINQ a nuestro producto" tipo de tareas que haces cuando no estás haciendo tu trabajo real. Eventualmente puede entrar en el tronco, puede que no, pero está allí y bajo el control de la versión. Sin IC aquí.
/ rama de proveedor estándar de proveedor para proyectos donde recopilamos pero no es código que mantenemos.
/ ccnet estas son nuestras etiquetas de CI, solo el servidor de CI puede escribir aquí. La retrospectiva nos hubiera dicho que cambiemos el nombre a algo más genérico como CI, BUILDS, etc.
Para Subversion, estoy de acuerdo con el comentario de Ryan Duffield. El capítulo al que se refiere proporciona buenos análisis sobre qué sistema usar.
La razón por la que pregunté es que Perforce proporciona una forma completamente diferente de crear ramas desde SVN o CVS. Además, están todos los DVCS que le dan su propia filosofía a la bifurcación. Su estrategia de ramificación estaría dictada por qué herramienta (s) está (n) utilizando.
FYI, Svnmerge.py es una herramienta para ayudar a fusionar sucursales en SVN. Funciona muy bien siempre que lo use con frecuencia (cada 10-30) se compromete, de lo contrario, la herramienta puede confundirse.
Para la guía de la madre sobre los patrones de ramificación, ver Líneas de flujo de Brad Appleton : Patrones de ramificación para el desarrollo paralelo de software . Es un trabajo pesado, pero no he visto nada que lo supere en términos de amplitud y profundidad de conocimiento sobre la ramificación.
Recomiendo leer la opinión de Eric Sink al respecto:
Yo, como Eric, prefiero la ramificación del estilo de "carpeta" de la que él habla.
Usamos el estilo salvaje, salvaje y al oeste de git-branches. Tenemos algunas sucursales que tienen nombres bien conocidos definidos por la convención, pero en nuestro caso, las etiquetas son en realidad más importantes para nosotros para cumplir con los requisitos de nuestra política de procesos corporativos.
A continuación, vi que usas Subversion, por lo que creo que probablemente deberías consultar la sección dedicada a la bifurcación en el Libro de Subversion . Específicamente, consulte la sección "diseño del repositorio" en Mantenimiento de sucursales y patrones de sucursales comunes .