¿Cuándo debe ramificar?

En términos generales, el propósito principal de la ramificación (una característica del Sistema de Control de Versiones VCS) es lograr el aislamiento de código .

Tiene al menos una rama, que puede ser suficiente para el desarrollo secuencial, y se usa para muchas tareas que se registran (confirman) en esa misma rama única.

Pero ese modelo muestra rápidamente su límite:

Cuando se tiene un esfuerzo de desarrollo (refactorización, evolución, corrección de errores,...) y te das cuenta de que no puedes hacer con seguridad esos cambios en la misma rama que tu rama de desarrollo actual (porque romperías la API, o introducirías código que rompería todo), entonces necesitas una otra rama.
(To isolate that new code for the legacy one, even though the two code sets will be merge later on)

Así que esa es tu respuesta:
Debe ramificar siempre que no pueda perseguir y registrar dos esfuerzos de desarrollo en una rama.
(sin tener un historia horriblemente complicada de mantener).

Una rama puede ser útil incluso si eres el único que trabaja en el código fuente, o si eres 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 "vamos a desarrollar la próxima versión de nuestro software" o tan específica como "vamos a corregir un error 23"),
no aislar un"recurso" .

(una rama llamado " VonC "no significa nada para otro desarrollador: ¿Qué pasa si" VonC " deja el proyecto? ¿Qué se supone que hagas 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 usarla con al menos alguna idea sobre lo que se supone que debe hacer con ella)

Una rama no es una etiqueta (SVN es un Sistema de revisión que intenta proponer características de control de versionescomo ramificación y etiquetado a través de directorios con copia de archivos barata: eso no significa que una etiqueta sea una rama)

Definir una rama significa también definir una flujo de trabajo de fusión: necesita saber dónde fusionar su rama cuando haya terminado con ella.
Para eso, el capítulo 7 de Practical Perforce (Laura WINGERD - O'Reilly) es una buena introducción (VCS agnostic) para combinar el flujo de trabajo entre diferentes tipos de ramas: " "Cómo Evoluciona el Software" (pdf)

Define el término codeline (rama que registra pasos de evolución significativos del código, ya sea a través de etiquetas en ciertos puntos, o a través de una combinación importante de vuelta a la rama)

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

• Flujos de desarrollo activos : una línea de código persistente cuando se producen varios desarrollos secuenciales
• ramas de tareas : ramas de corta duración para más tarea específica (bug-fix es un clásico, 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 problemas para la rama de desarrollo actual principal)
• staging branch: para preparar una versión, con algunos datos específicos de preproducción o archivos de configuración.
• Ramas privadas, ramas ad hoc, y ramas dispersas: para tareas muy pequeñas, solo para poder algunos trabajos en curso sin esperar a la finalización formal o revisión de la prueba.
  Eso permite "comprometerse temprano, comprometerse a menudo".

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

Todos los SCM del siglo 21 te están diciendo:

Rama para cada tarea en la que tenga que trabajar, no importa si se trata de una nueva característica, una corrección de errores, una prueba, lo que sea. Esto se llama rama temática y cambia la forma de trabajar con el SCM.

Obtienes:

• Mejor aislamiento
• Mejor trazabilidad- > asocias tareas con ramas, no con conjuntos de cambios individuales, lo que te hace libre de comprometer tantas veces como quieras y no impone un límite como "one checkin per task" (en inglés).
• Las tareas son independientes (normalmente a partir de una línea de base estable, por lo que solo se centra en su código, no en la corrección de errores de sus amigos), 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 por gilipolleces previas a la confirmación) antes de golpear la línea principal

Herramientas que pueden hacerlo:

• Git
• Mercurial
• Plástico SCM

Herramientas que NO pueden hacerlo:

• SVN
• CVS
• VSS
• TFS
• Forzosamente

También depende de la herramienta SCM que esté utilizando. SCMS modernos (git, mercurial, etc.) hacer que sea cada vez más fácil crear y destruir ramas cuando sea necesario. Esto le permite, por ejemplo, hacer una rama por bug en el que está trabajando. Una vez que se fusionan los resultados en el tronco, se 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 un parche de veinte y tantos. Allí, las ramas se utilizan clásicamente para rastrear pistas de desarrollo completas, como una versión de producto anterior o futura.

Cuando necesita hacer cambios significativos y/o experimentales en su base de código, particularmente si desea confirmar cambios intermedios, sin afectar el tronco.

Depende del tipo de SCM que esté utilizando.

En las versiones distribuidas más recientes (como git y mercurial), estás creando ramas todo el tiempo y remergiendo de todos modos. A menudo trabajaré 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á caída, y luego la fusión cambia más tarde cuando se arregla, y es tan fácil de hacer que ni siquiera es molesto.

El documento (corto y legible) que más me ayudó understand what was going in in the distributed systems is: 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 antigua mientras se permite que el desarrollo continúe en la línea principal', o 'como parte de un experimento mayor'.

El modelo distribuido es mucho mejor, creo, y solo falta bonitas 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 ser confuso para los nuevos usuarios.

Creo que el consejo de Laura Wingerd y Christopher Seiwald en Perforce es realmente 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.

Véase http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf para 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ística/error. Ramas dinámicas y activas que se vuelven a mover al tronco cuando se completa la característica/corrección de error.
2. Ramas estáticas (etiquetas en Subversion, aunque en esencia solo una 'rama normal'). Proporcionan una instantánea estática de, por ejemplo, una liberación. A pesar de que podrían ser trabajados, permanecen intactos.

La necesidad de ramificación también puede surgir:

Cuando quieras.

Probablemente no será muy frecuente si trabaja con un SCM centralizado ya que las ramas son parte del repositorio oficial, y eso realmente no invita a mucha experimentación, por no mencionar que las fusiones realmente dañan.

OTOH, no hay diferencia técnica entre una rama y un checkout en SCM distribuidos, y las fusiones son mucho más fáciles. Tendrás ganas de ramificar mucho más a menudo.

Cuando necesite hacer 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 trunk. Alrededor del momento del lanzamiento, alguien va a necesitar hacer un cambio que no queremos en la versión actual (puede ser antes del lanzamiento, en este momento es generalmente después del lanzamiento). Esto es cuando nos ramificamos, para poner la versión en su propia rama y continuar el desarrollo para la próxima versión en trunk.

Dejando de lado todos los tecnicismos.....

Rama cuando se sabe que es más fácil de fusionar de nuevo!

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

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