En primer lugar, como señalan @AndrewFinnell y @KenLiu, en SVN los nombres de directorio en sí mismos no significan nada: "troncal, ramas y etiquetas" son simplemente una convención común utilizada por la mayoría de los repositorios. No todos los proyectos usan todos los directorios (es razonablemente común no usar "etiquetas") y, de hecho, nada le impide llamarlos como desee, aunque romper la convención a menudo es confuso.
Probablemente describiré el escenario de uso más común de ramas y etiquetas, y daré un ejemplo de cómo se usan.
Tronco : El área principal de desarrollo. Aquí es donde vive su próxima versión principal del código, y generalmente tiene todas las características más nuevas.
Ramas : cada vez que lanzas una versión principal, se crea una rama. Esto le permite hacer correcciones de errores y hacer una nueva versión sin tener que lanzar las características más recientes, posiblemente sin terminar o sin probar.
Etiquetas : cada vez que lanza una versión (versión final, versión candidatas (RC) y versiones beta), crea una etiqueta para ella. Esto le proporciona una copia del código en un punto en el tiempo tal como estaba en ese estado, lo que le permite regresar y reproducir cualquier error si es necesario en una versión anterior, o volver a lanzar una versión anterior exactamente como estaba. Las ramas y etiquetas en SVN son livianas: en el servidor, no hace una copia completa de los archivos, solo un marcador que dice "estos archivos se copiaron en esta revisión" que solo ocupa unos pocos bytes. Con esto en mente, nunca debe preocuparse por crear una etiqueta para ningún código publicado. Como dije anteriormente, las etiquetas a menudo se omiten y, en cambio, un registro de cambios u otro documento aclara el número de revisión cuando se realiza un lanzamiento.
Por ejemplo, supongamos que comienza un nuevo proyecto. Empiezas a trabajar en "trunk", en lo que finalmente se lanzará como versión 1.0.
- tronco / - versión de desarrollo, próximamente 1.0
- ramas / - vacías
Una vez que finaliza 1.0.0, ramifica el tronco en una nueva rama "1.0" y crea una etiqueta "1.0.0". Ahora trabaje en lo que finalmente será 1.1 continúa en el tronco
- tronco / - versión de desarrollo, que pronto será 1.1
- sucursales / 1.0 - 1.0.0 versión de lanzamiento
- tags / 1.0.0 - 1.0.0 versión de lanzamiento
Te encuentras con algunos errores en el código, los reparas en el tronco y luego combinas las correcciones en la rama 1.0. También puede hacer lo contrario y corregir los errores en la rama 1.0 y luego fusionarlos nuevamente con el tronco, pero comúnmente los proyectos se quedan con la fusión en un solo sentido para disminuir la posibilidad de perder algo. A veces, un error solo se puede corregir en 1.0 porque es obsoleto en 1.1. Realmente no importa: solo desea asegurarse de no lanzar 1.1 con los mismos errores que se han corregido en 1.0.
- tronco / - versión de desarrollo, que pronto será 1.1
- sucursales / 1.0 - próxima versión 1.0.1
- tags / 1.0.0 - 1.0.0 versión de lanzamiento
Una vez que encuentre suficientes errores (o tal vez un error crítico), decide hacer una versión 1.0.1. Entonces crea una etiqueta "1.0.1" desde la rama 1.0 y libera el código. En este punto, el tronco contendrá lo que será 1.1, y la rama "1.0" contiene el código 1.0.1. La próxima vez que lance una actualización a 1.0, sería 1.0.2.
- tronco / - versión de desarrollo, que pronto será 1.1
- sucursales / 1.0 - próxima versión 1.0.2
- tags / 1.0.0 - 1.0.0 versión de lanzamiento
- tags / 1.0.1 - 1.0.1 versión de lanzamiento
Finalmente, está casi listo para lanzar la versión 1.1, pero primero desea hacer una versión beta. En este caso, probablemente haga una rama "1.1" y una etiqueta "1.1beta1". Ahora, el trabajo en lo que será 1.2 (o tal vez 2.0) continúa en el tronco, pero el trabajo en 1.1 continúa en la rama "1.1".
- tronco / - versión de desarrollo, próximamente 1.2
- sucursales / 1.0 - próxima versión 1.0.2
- sucursales / 1.1 - próxima versión 1.1.0
- tags / 1.0.0 - 1.0.0 versión de lanzamiento
- tags / 1.0.1 - 1.0.1 versión de lanzamiento
- tags / 1.1beta1 - 1.1 beta 1 versión de lanzamiento
Una vez que liberas 1.1 final, haces una etiqueta "1.1" desde la rama "1.1".
También puede continuar manteniendo 1.0 si lo desea, portando correcciones de errores entre las tres ramas (1.0, 1.1 y troncal). La conclusión importante es que para cada versión principal del software que está manteniendo, tiene una rama que contiene la última versión del código para esa versión.
Otro uso de las ramas es para las características. Aquí es donde ramifica el tronco (o una de sus ramas de lanzamiento) y trabaja en una nueva característica de forma aislada. Una vez que se completa la función, la vuelve a fusionar y elimina la rama.
- tronco / - versión de desarrollo, próximamente 1.2
- sucursales / 1.1 - próxima versión 1.1.0
- sucursales / ui-rewrite - rama de características experimentales
La idea de esto es cuando estás trabajando en algo disruptivo (que podría retrasar o interferir con otras personas para que hagan su trabajo), algo experimental (que tal vez ni siquiera lo logre), o posiblemente algo que lleva mucho tiempo (y tiene miedo de que mantenga una versión 1.2 cuando esté listo para ramificarse 1.2 desde el tronco), puede hacerlo de forma aislada en rama. En general, lo mantiene actualizado con troncal fusionando los cambios en él todo el tiempo, lo que facilita la reintegración (fusión a troncal) cuando haya terminado.
También tenga en cuenta que el esquema de versiones que utilicé aquí es solo uno de muchos. Algunos equipos realizarían versiones de mantenimiento / corrección de errores como 1.1, 1.2, etc., y cambios importantes como 1.x, 2.x, etc. El uso aquí es el mismo, pero puede nombrar la rama "1" o "1 .x "en lugar de" 1.0 "o" 1.0.x ". (Además, el control de versiones semántico es una buena guía sobre cómo hacer los números de versión).
