version control - usados - ¿Cuándo deberías ramificarte?
sistemas de control de versiones mas usados (12)
Cuando se trabaja con un sistema SCM, ¿cuándo se debe ramificar?
Cuando necesite realizar cambios significativos y / o experimentales en su base de código, particularmente si desea comprometer cambios intermedios, sin afectar el enlace troncal.
Cuando necesite realizar cambios, en función de su rama actual, no destinados a la próxima versión de esa rama (y no antes).
Por ejemplo, trabajamos en el tronco generalmente. En el momento de la publicación, alguien tendrá que hacer un cambio que no queremos en la versión actual (puede ser antes del lanzamiento, en el momento en que suele ser después del lanzamiento). Esto es cuando ramificamos, para poner el lanzamiento en su propia rama y continuar el desarrollo para el próximo lanzamiento en el tronco.
Cuando quiera.
Probablemente no lo harás con mucha frecuencia si trabajas con un SCM centralizado ya que las sucursales son parte del repositorio oficial, y eso realmente no invita a mucha experimentación, sin mencionar que las fusiones realmente duelen.
OTOH, no hay diferencia técnica entre una sucursal y un pago en SCM distribuidos, y las fusiones son mucho más fáciles. Sentirá ganas de ramificarse mucho más a menudo.
Dejando todos los detalles técnicos a un lado .....
¡Rama cuando sepa que es más fácil fusionarse de nuevo!
Teniendo en cuenta que la fusión siempre se verá afectada por la forma en que se lleva a cabo el trabajo en un proyecto.
Una vez que esto se logre, todos los demás asuntos terciarios entrarán en juego.
Depende del tipo de SCM que estés usando.
En las versiones distribuidas más nuevas (como git y mercurial), estás creando ramas todo el tiempo y volviendo a crearlas de todos modos. A menudo trabajaré en una sucursal separada por un tiempo solo porque alguien rompió la compilación en la línea principal, o porque la red no funciona, y luego se fusiona los cambios más tarde cuando se solucionó, y es tan fácil de hacer que ni siquiera es molesto .
El documento (breve y legible) que más me ayudó a entender lo que estaba pasando en los sistemas distribuidos es: UnderstandingMercurial .
En los sistemas más antiguos con un repositorio central (como CVS, SVN y ClearCase), se trata de un problema mucho más serio que debe decidirse a nivel de equipo, y la respuesta debería ser más bien "mantener una versión anterior al tiempo que se permite desarrollo para continuar en la línea principal ''o'' como parte de un experimento importante ''.
El modelo distribuido es mucho mejor, creo, y le faltan solo buenas herramientas gráficas para convertirse en el paradigma dominante. Sin embargo, no es tan ampliamente entendido, y los conceptos son diferentes, por lo que puede ser confuso para los nuevos usuarios.
El consejo de Laura Wingerd y Christopher Seiwald en Perforce es muy conciso y útil:
* Branch only when necessary.
* Don''t copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.
Consulte http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf para obtener una explicación detallada de cada uno de ellos y otras mejores prácticas.
En términos generales, el propósito principal de la bifurcación (un VCS - Sistema de control de versiones - característica) es lograr el aislamiento del código.
Tiene al menos una rama, que puede ser suficiente para el desarrollo secuencial, y se utiliza para muchas tareas que se registran (confirmadas) en esa misma rama única.
Pero ese modelo muestra rápidamente su límite:
Cuando tiene un esfuerzo de desarrollo (refactorización, evolución, corrección de errores, ...) y se da cuenta de que no puede realizar esos cambios de forma segura en la misma rama que su rama de desarrollo actual (porque rompería la API o introduciría un código que rompería todo), entonces necesitas otra rama.
(Para aislar ese nuevo código para el legado, aunque los dos conjuntos de códigos se fusionen más adelante)
Entonces esa es tu respuesta allí mismo:
Debes ramificar cada vez que no puedas perseguir y registrar dos esfuerzos de desarrollo en una rama.
(sin tener una historia terriblemente complicada de mantener).
Una rama puede ser útil incluso si usted es el único que trabaja en el código fuente, o si usted es muchos.
Pero no debe hacer "una rama por desarrollador":
el propósito de "aislamiento" es aislar un esfuerzo de desarrollo (una tarea que puede ser tan general como "desarrollemos la próxima versión de nuestro software" o tan específico como "arreglemos el error 23"),
no aislar un "recurso" .
(Una rama llamada "VonC" no significa nada para otro desarrollador: ¿Qué pasa si "VonC" abandona el proyecto? ¿Qué se supone que debes hacer con él?
una rama llamada "bugfix_212" se puede interpretar en el contexto de un sistema de seguimiento de errores, por ejemplo, y cualquier desarrollador puede usarlo con al menos alguna idea sobre lo que se supone que debe hacer con él)
Una rama no es una etiqueta (SVN es un sistema de revisión que intenta proponer funciones de versionado como ramificación y etiquetado a través de directorios con copia de archivo barata: eso no significa que una etiqueta sea una rama)
Definir una rama significa también definir un flujo de trabajo de fusión : debe saber dónde fusionar su sucursal cuando haya terminado con ella.
Para eso, el capítulo 7 de Practical Perforce (Laura WINGERD - O''Reilly) es una buena introducción (agnóstico de VCS) para fusionar el flujo de trabajo entre diferentes tipos de ramas: " Cómo evoluciona el software " (pdf)
Define el término línea de código (rama que registra los pasos de evolución significativos del código, ya sea a través de etiquetas en ciertos puntos, o mediante una fusión importante de vuelta a la rama)
Introduce el modelo principal (una línea de código central para registrar las versiones) y describe varios propósitos para la bifurcación:
- Flujos de desarrollo activo : una línea de código persistente cuando se producen varios desarrollos secuenciales
- ramas de tareas : ramas efímeras para tareas más específicas (la corrección de errores es clásica, pero también puede definir una rama para un esfuerzo de fusión que usted sabe que es complejo completar: puede fusionar, comprometer y probar en esa rama de tareas) sin introducir problema para la rama principal de desarrollo actual)
- bifurcación de etapas : para preparar una publicación, con algunos datos específicos de preproducción o archivos de configuración.
- Sucursales privadas, sucursales ad hoc y ramas dispersas : para tareas muy pequeñas, solo para poder comprometer algún trabajo en progreso sin esperar la finalización formal o la revisión de la prueba.
Eso permite "comprometerse temprano, comprometerse a menudo".
Otros conceptos interesantes sobre VCS: Conceptos básicos
(sobre ClearCase originalmente, pero también válido para cualquier VCS)
Hay varios propósitos para la ramificación:
- Ramas de funciones / errores. Las ramas dinámicas y activas que se vuelven a mover al tronco cuando se completa la función / corrección de errores.
- Ramas estáticas (etiquetas en Subversion, aunque en esencia solo una ''rama normal''). Proporcionan una instantánea estática de, digamos, un lanzamiento. A pesar de que podrían ser trabajados, permanecen intactos.
La necesidad de ramificación también puede surgir:
Todos los SCM del siglo XXI te dicen:
Rama para cada tarea en la que deba trabajar , sin importar si esta es una característica nueva, una corrección de errores, una prueba o lo que sea. Esto se llama rama de tema y cambia la forma en que trabaja con su SCM.
Usted obtiene:
- Mejor aislamiento
- Mejor trazabilidad -> asocia tareas con sucursales, no conjuntos de cambios individuales, lo que le permite comprometerse tantas veces como quiera y no impone un límite como "una comprobación por tarea".
- Las tareas son independientes (normalmente a partir de una línea base estable, por lo que solo se enfoca en su código, no en corregir errores de su gente), y puede elegir si desea integrarlos en algún momento o más adelante, pero siempre están bajo control de versiones
- Puede revisar el código fácilmente (desde el control de versiones, no antes de cometer errores) antes de llegar a la línea principal
Herramientas que pueden hacerlo:
Herramientas que NO PUEDEN hacerlo:
- SVN
- CVS
- VSS
- TFS
- Forzosamente
Hay varios usos para la ramificación. Uno de los usos más comunes es para separar proyectos que alguna vez tuvieron una base de código común. Esto es muy útil para experimentar con su código, sin afectar el tronco principal.
En general, vería dos tipos de ramas:
Feature Branch: si una característica en particular es lo suficientemente perturbadora como para no querer que todo el equipo de desarrollo se vea afectado en sus etapas iniciales, puede crear una rama para realizar este trabajo.
Fixes Branch: mientras el desarrollo continúa en la troncal principal, se puede crear una rama de arreglos para mantener las correcciones a la última versión del software lanzada.
Puede que esté interesado en consultar el siguiente artículo, que explica los principios de la bifurcación y cuándo usarlos:
También depende de la herramienta SCM que esté utilizando. Los SCM modernos (git, mercurial, etc.) hacen que sea cada vez más fácil crear y destruir ramas cuando sea necesario. Esto le permite, por ejemplo, crear una ramificación por error en la que esté trabajando. Una vez que fusionas tus resultados en el tronco, descartas la rama.
Otros SCM, por ejemplo, subversión y CVS, tienen un paradigma de ramificación mucho más "pesado". Eso significa que una rama se considera apropiada solo para algo más grande que un parche de veintitantos líneas. Allí, las sucursales se utilizan clásicamente para rastrear pistas de desarrollo completas, como una versión de producto anterior o futura.