svn - tag - ¿Es posible usar el modelo de git-flow con Subversion?

merge branches subversion (3)

En mis actividades utilizo SVN con el siguiente enfoque.

El tronco es la rama "maestra". Nunca debes cometer nada directamente en el maletero. Trunk siempre debe coincidir exactamente con la última versión lanzada en producción. Entonces, el tronco siempre representa una rama estable. El tronco se actualiza solo con la reintegración de las ramas.
Necesitas sucursales para tu trabajo. Cada nueva rama debe crearse desde el tronco, por lo que cada nueva rama coincide exactamente con la versión de producción en el momento de la creación. Los cambios y las correcciones se confirman en las sucursales.
Debes tener al menos 2 ramas principales:
- desarrollar: destinado a desarrollos futuros que aún no están planificados para su lanzamiento.
- revisión: utilizada para confirmar todas las correcciones de errores y solo correcciones. Para uso frecuente, debe actualizarse con la versión troncal cuando se actualice el troncal.
Cree una rama para cada flujo de trabajo principal: un proyecto, un subproyecto, una solicitud de cambio. Puedes trabajar con desarrollos paralelos.
Crea ramas de "integración" para unir ramas que tienes que lanzar. Debe fusionarse en la rama de integración en cada una de las sucursales candidatas al lanzamiento. Por lo tanto, la rama de integración puede unir tanto la revisión como un proyecto, por ejemplo.
Construye tus artefactos desde las ramas de integración o desde las ramas.
Cuando haya lanzado una rama, cree la etiqueta para esa versión, para que pueda tener una copia de la versión publicada y aún pueda trabajar con la rama. En las etiquetas solo debería haber lanzado la versión. ¡No confirme cambios en la etiqueta!
Después de que se libera una rama, debe actualizar el tronco. Entonces reintegra la rama en el tronco. Puede reintegrar una rama de integración, o la rama directamente (si no pasó de la integración).
Cuando el tronco vuelva a coincidir con la versión de producción, infórmalo en todas las ramas activas.

Este método no es realmente una réplica del concepto de git-flow, pero sigue algunos de sus requisitos.

Con este enfoque, puede tener las siguientes ventajas:

el tronco es estable. Siempre sabes qué tronco representa en ese momento.
Cada rama contiene solo sus propios cambios.
Con las sucursales de integración puede gestionar ramas paralelas en una sola versión
Con las etiquetas siempre tienes una copia de una versión lanzada

Las desventajas son:

Muchas ramas para administrar.
Necesita fusionarse y cambiar muy a menudo, especialmente para informar los cambios en las ramas de integración
Muchos conflictos para resolver cada vez

Por cierto, este es el mejor enfoque con el que he trabajado porque te permite mantener el control de las versiones.

Usamos Subversion y aparte de algunos individuos como yo, hay poca o ninguna experiencia con la ramificación y la fusión en Subversion. Mi experiencia en Subversion está limitada a las ramas de funciones simples donde los conflictos de fusión y de árbol, aunque no son exactamente raros, no son excesivamente difíciles de resolver.

Dado que, estoy ayudando a administrar un proyecto donde nuestro compromiso actual con el método troncal es simplemente insostenible para nuestras necesidades. Introduje la función de ramificación y fusión en mi equipo localizado y tuvimos cierto éxito. Sin embargo, la ramificación de funciones simples aún no podía responder a todas nuestras preguntas, como por ejemplo:

¿Cómo desarrollamos código en paralelo para este lanzamiento y lanzamientos posteriores?
¿Qué código se considera estable?
¿Qué código (en desarrollo) está entrando en la próxima versión?
¿Qué código (en desarrollo) va a una versión posterior?
¿Qué versión de código tienen nuestros entornos de Prueba, Aceptación o Producción?
¿Cómo integramos las actividades de desarrollo simultáneas con una versión estable conocida para reducir la introducción de errores y el trabajo incompleto?
¿Cómo proporcionamos correcciones para el código publicado?
¿Cómo sabemos, desde nuestro control de fuente, qué actividad de desarrollo está actualmente en curso?
¿Cómo experimentamos o R & D sin interrumpir la base de código actual mientras aprovechamos?

Parece que git-flow, como se define aquí, sería un gran paso para responder muchas de estas preguntas. Experimenté con este método en Mercurial y parece que también es posible implementar este método allí. Lamentablemente, migrar a un DVCS está fuera de la mesa en este punto.

Sin embargo, mi breve intento de imitar este método en Subversion falló con muchos conflictos de fusión y árbol. Las opciones de combinación y los casos de borde son numerosos y desconcertantes.

¿Se puede usar Subversion para implementar gitflow y, de ser así, cuál es el nivel de dolor?

Esa es una gran pregunta. Solo tengo ideas de cómo resolver algunos de los problemas:

No creo que esto pueda resolverse fácilmente sin usar muchas ramas. No estoy seguro si esto se puede resolver fácilmente usando GIT tampoco. Las ramas de características son importantes para resolver este problema, pero en general, probablemente debas concentrarte solo en las características para la próxima versión.
trunk : lo considero la rama master .
Yo diría que la rama de development es el código para la próxima versión
Parece difícil sin usar muchas ramas, ni idea de cómo resolverlo adecuadamente.
Puede usar ramas o anotar el número de revisión en TEST y ACC. PROD debería ponerse en una etiqueta, supongo.
Yo diría que usa pruebas de regresión automáticas e integración continua. También el uso de revisiones por pares puede ser útil aquí; en el mejor de los casos, utiliza algún tipo de herramienta para marcar un archivo como revisado. De esta forma, puede asegurarse de que solo combine los archivos que se han revisado. También podría ser interesante vincular los mensajes de confirmación a su rastreador de errores, para descubrir automáticamente qué archivos se tocaron en relación con los problemas y luego asegurarse de que todos los problemas se cierren para los archivos que desea combinar. Esta es una tarea no trivial, especialmente si está pensando fusionar solo partes de ramas. De esta manera, más o menos, haciendo una combinación de características.
Use una etiqueta para el lanzamiento. Puede verificarlo como una rama y agregar parches si es necesario
Listar todos los commit de svn para todo el repositorio en una página (por ejemplo, trac / redmine / jira overview)
Use una copia local Me temo / o una rama nuevamente. O haz que la I + D use git svn localmente para investigación.

Algunos de estos problemas pueden resolverse, al menos en parte, usando git svn . Al usarlo, puede, por ejemplo, realizar experimentos de forma local utilizando gits branch features, sin almacenarlos en el repositorio global. Por supuesto, esto no es interesante si está explorando una nueva función con muchos miembros en un equipo, a menos que se sientan cómodos con el uso de git y separándose entre sí a través de la red. Al usar git svn , también puedes usar git cherrypick para elegir manualmente commits únicos para aplicar de una rama a otra (por ejemplo, desarrollo en la etiqueta-xx liberada).

Eso es todo lo que podría hacer por ahora, espero que ayude.

Usamos lo que se llama el método de desarrollo de troncales inestable . Esta fue la metodología de desarrollo que los creadores de Subversion tenían en mente cuando crearon Subversion. Es simple y fácil de implementar.

Usted hace todo su desarrollo en el tronco . Así llamado el tronco inestable.
Cuando te acercas a un lanzamiento, creas una rama para ese lanzamiento. La idea es hacer que la rama sea lo suficientemente tarde como para mantener el desarrollo paralelo lo más corto posible, pero no tan tarde que algunos desarrolladores no pueden hacer su trabajo porque ya no necesitan trabajar en la versión actual, sino que necesitan comenzar a trabajar en la próximo lanzamiento. En Ágil, esto generalmente se hace justo antes del sprint reafirmante . Por lo general, se realiza cuando el lanzamiento está completo, y ahora solo estás corrigiendo errores.
La liberación se lleva a cabo fuera de la sucursal. Usted etiqueta fuera de la rama. Si hay parches que se necesitan, se eliminan de la sucursal.

Aquí hay una idea de cómo funciona:

Imagina que estás trabajando en la Versión 1.2. Estás trabajando en el maletero. Ahora, se está acercando al momento en que se lanzará la Versión 1.2, y no hay suficiente trabajo en la Versión 1.2 para mantener ocupados a los desarrolladores. Usted crea una rama 1.2 para su lanzamiento.
Ahora, las personas que todavía trabajan en la versión 1.2 cambian a la rama de la versión 1.2. Mientras tanto, los desarrolladores que trabajan en 1.3 permanecen en el tronco .
Ahora está listo para la versión 1.2. Etiqueta la versión 1.2 directamente en la rama. La rama no se fusiona nuevamente en el tronco. El tronco es para la versión 1.3.
Se informan errores y desea corregirlos en la versión 1.2.1. Continúa trabajando fuera de la rama 1.2. No se necesita una nueva rama para 1.2.1. (Puede bloquear ramas entre lanzamientos para mantenerlas puras .
Cuando esté a punto de hacer la versión 1.3, repita el proceso: la rama 1.3 y el trabajo para 1.4 continúa en la línea externa.

Habrá un poco de fusión. Se trata principalmente de fusionar los defectos corregidos en la rama de liberación de nuevo al tronco. Hay tres opciones para hacer esto:

Una vez que haces un lanzamiento, fusionas todos los cambios en la rama de nuevo en el tronco. Hay muy poco seguimiento. Simplemente está asumiendo que todas las correcciones de errores en la rama también se aplican al tronco.
Utiliza un sistema de seguimiento que entiende que los problemas pueden vivir en más de un lanzamiento. En este caso, simplemente marca un error descubierto en la rama en el tronco también. Puede seleccionar cambios que se apliquen al tronco gracias a su sistema de seguimiento de problemas.
Algunos sitios simplemente no se fusionan. También rastrean a través de los cambios del sistema de seguimiento de defectos que deben aplicarse al tronco que se aplicaron en la rama, y simplemente los vuelven a implementar. Pueden copiar los cambios de la rama al tronco, pero nunca hacen una fusión formal. Sin embargo, una vez que haces esto, no puedes fusionar (a menos que te --record-only con el --record-only ).

Usted, por supuesto, se da cuenta de que este método requiere algo llamado planificación . Debe priorizar su trabajo, para que los desarrolladores hagan el trabajo para la próxima versión antes de trabajar en la versión futura. Solo se ramifica una vez que ya no tiene suficiente trabajo en la próxima versión para mantener ocupados a todos sus desarrolladores.

Puede implementar el flujo de trabajo estándar de Git, que utiliza ramas de desarrollo por separado para cada desarrollador o problema, y luego entrega esos cambios en el enlace troncal. Esto requeriría muchas ramas, una para cada desarrollador / función.

Primero se fusiona del tronco a la rama para volver a establecer la base de su código. Una vez que haya hecho la rebase, se fusionará de la rama a la troncal mediante el interruptor --reintegrate . Antes de la --reintegrate 1.6, se suponía que --reintegrate eliminar la rama y volver a --reintegrate ya que se --reintegrate tipo de seguimiento de fusión desordenado. Sin embargo, esto se ha solucionado en la versión 1.6.xy superior.