¿Cuándo debes bifurcar?

Cuando se trabaja con un sistema SCM, ¿cuándo debería bifurcarse?

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á dos tipos de rama:

• Rama de funciones: si una función en particular es lo suficientemente disruptiva como para que no desee que todo el equipo de desarrollo se vea afectado en sus primeras etapas, puede crear una rama en la que realizar este trabajo.

• Rama de correcciones: mientras continúa el desarrollo en el tronco principal, se puede crear una rama de correcciones para mantener las correcciones en la última versión publicada del software.

Puede que le interese consultar el siguiente artículo, que explica los principios de la ramificación y cuándo utilizarlos:

• Ned Batchelder - Inicio rápido de ramificación de Subversion

En términos generales, el propósito principal de la ramificación (una característica de VCS - Version Control System -) 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 (confirman) 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 manera segura en la misma rama que su rama de desarrollo actual (porque rompería la API o introduciría código que rompería todo), entonces necesitas otra rama.
( Aislar ese nuevo código para el heredado, aunque los dos conjuntos de códigos se fusionarán más adelante)

Así que esa es su respuesta allí mismo:
debe bifurcarse siempre que no pueda continuar y registrar dos esfuerzos de desarrollo en una rama.
(sin tener una historia horriblemente complicada que mantener).

Una rama puede ser útil incluso si eres el único que trabaja en el código fuente, o si son muchos.
Pero no debe hacer "una rama por desarrollador":
el propósito de "aislamiento" se hace para 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ífica como "arreglemos error 23 "),
no para 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 ella?
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 control de versiones como la ramificación y el 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 : necesita saber dónde fusionar su rama cuando haya terminado con ella.
Por eso, el capítulo 7 de Practical Perforce (Laura WINGERD - O'Reilly) es una buena introducción (independiente 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 regreso a la rama)

Introduce el modelo de línea principal (una línea de código central para registrar lanzamientos) y describe varios propósitos para la ramificación:

• Flujos de desarrollo activos : una línea de código persistente cuando tienen lugar varios desarrollos secuenciales
• ramas de tareas : ramas de corta duración 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 sabe que es complejo de completar: puede fusionar, confirmar y probar en esa rama de tarea sin introducir problema para la rama principal de desarrollo actual)
• rama de ensayo : para preparar una versión, con algunos datos específicos de preproducción o archivos de configuración.
• Sucursales privadas, sucursales ad hoc y sucursales dispersas : para tareas muy pequeñas, solo para poder realizar algún trabajo en progreso sin esperar a que se complete formalmente o se revise la prueba.
  Eso permite "comprometerse temprano, comprometerse a menudo".

_{Otros conceptos interesantes en torno a VCS: conceptos básicos
(sobre ClearCase originalmente, pero también válido para cualquier VCS)}

Todos los SCM del siglo XXI le están diciendo:

Bifurca para cada tarea en la que tengas que trabajar , sin importar si se trata de una función nueva, una corrección de errores, una prueba, 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 ramas, no conjuntos de cambios individuales, lo que le da la libertad de comprometerse tantas veces como desee y no impone un límite como "un registro por tarea".
• Las tareas son independientes (normalmente comienzan desde una línea de base estable, por lo que solo se enfoca en su código, no en corregir errores de su gente), y puede elegir si desea integrarlas en algún momento o más tarde, pero siempre están bajo control de versiones
• Puede revisar el código fácilmente (desde el control de versiones, no pre-cometer tonterías) antes de llegar a la línea principal

Herramientas que pueden hacerlo:

• Git
• Mercurial
• SCM de plástico

Herramientas que NO PUEDEN hacerlo:

• SVN
• CVS
• VSS
• TFS
• Forzosamente

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, hacer una rama por error en el que esté trabajando. Una vez que fusiona sus resultados en el tronco, descarta la rama.

Otros SCM, por ejemplo, Subversion 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 veinte y tantos líneas. Allí, las sucursales se utilizan clásicamente para rastrear pistas de desarrollo completas, como una versión anterior o futura del producto.

Cuando necesite realizar cambios significativos y / o experimentales en su base de código, especialmente si desea realizar cambios intermedios, sin afectar el tronco.

Depende del tipo de SCM que esté utilizando.

En las versiones distribuidas más nuevas (como git y mercurial), está creando ramas todo el tiempo y resurgiendo de todos modos. A menudo trabajo en una rama separada por un tiempo solo porque alguien ha roto la compilación en la línea principal, o porque la red está inactiva, y luego fusiono los cambios más tarde cuando está arreglado, 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), entonces es un problema mucho más serio que debe decidirse a nivel de equipo, y la respuesta debería ser más como 'mantener una versión anterior mientras se permite desarrollo para continuar en la línea principal ', o' como parte de un gran experimento '.

El modelo distribuido es mucho mejor, creo, y carece solo de buenas herramientas gráficas para convertirse en el paradigma dominante. Sin embargo, no se entiende tan ampliamente y los conceptos son diferentes, por lo que puede resultar confuso para los nuevos usuarios.

Encuentro que los consejos de Laura Wingerd y Christopher Seiwald en Perforce son realmente concisos y útiles:

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

Hay varios propósitos para la ramificación:

1. Ramas de características / errores. Ramas dinámicas y activas que se mueven nuevamente al tronco cuando se completa la función / corrección de errores.
2. Ramas estáticas (etiquetas en Subversion, aunque en esencia solo una 'rama normal'). Proporcionan una instantánea estática de, digamos, una liberación. A pesar de que podrían ser trabajadas, permanecen intactos.

También puede surgir la necesidad de ramificación:

Siempre que te apetezca.

Probablemente no lo hará con mucha frecuencia si trabaja con un SCM centralizado, ya que las ramas 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. Tendrás ganas de ramificarte mucho más a menudo.

Cuando necesite realizar cambios, basados ​​en su rama actual, no destinados a la próxima versión de esa rama (y no antes).

Por ejemplo, normalmente trabajamos en el maletero. En el momento del lanzamiento, alguien tendrá que hacer un cambio que no queremos en el lanzamiento actual (puede ser antes del lanzamiento, en este momento suele ser después del lanzamiento). Aquí es cuando nos ramificamos, para poner la versión en su propia rama y continuar el desarrollo para la próxima versión en el tronco.

Dejando a un lado todos los tecnicismos .....

¡Bifurca cuando sepas que es más fácil volver a fusionar!

Teniendo en cuenta que la fusión siempre se efectuará con la forma en que se realiza el trabajo en un proyecto.

Una vez que esto se logre, todos los demás temas terciarios entrarán en juego.