En el control de versiones y la gestión de configuración de software , la ramificación consiste en duplicar un objeto bajo control de versiones (como un archivo de código fuente o un árbol de directorios ). Posteriormente, cada objeto puede modificarse de forma independiente y en paralelo, de modo que los objetos resultantes sean diferentes. En este contexto, los objetos se denominan ramas . Los usuarios del sistema de control de versiones pueden crear cualquier rama.
Las ramas también se conocen como árboles , flujos o líneas de código . La rama de origen a veces se denomina rama principal , rama ascendente (o simplemente ascendente , especialmente si las ramas son mantenidas por diferentes organizaciones o individuos) o flujo de respaldo .
Trompa
Las ramas hijas son ramas que tienen un padre; una rama sin padre se denomina tronco o línea principal . [ 1 ] El tronco también se denomina a veces de forma informal HEAD, pero propiamente head no se refiere a una rama, sino a la confirmación más reciente en una rama determinada, y tanto el tronco como cada rama nombrada tienen su propio head. El tronco suele ser la base de un proyecto sobre la que progresa el desarrollo. Si los desarrolladores trabajan exclusivamente en el tronco (el llamado desarrollo basado en el tronco ), este siempre contiene la última versión de vanguardia del proyecto, pero por lo tanto también puede ser la versión más inestable. Otro enfoque es separar una rama del tronco, implementar cambios en esa rama y fusionar los cambios de nuevo en el tronco cuando la rama haya demostrado ser estable y funcional. Dependiendo del modo de desarrollo y la política de confirmación , el tronco puede contener la versión más estable, la menos estable o una intermedia. Otros términos para tronco incluyen línea base, línea principal y master, aunque en algunos casos se utilizan con sentidos similares pero distintos; véase control de versiones § Terminología común . A menudo, el trabajo principal de los desarrolladores se realiza en la rama principal (trunk), se crean ramas para las versiones estables y, ocasionalmente, se incorporan correcciones de errores de las ramas a la rama principal. Cuando el desarrollo de versiones futuras se realiza en ramas que no son la principal, suele ser para proyectos que no cambian con frecuencia o donde se prevé que un cambio tardará mucho tiempo en desarrollarse hasta que esté listo para su incorporación a la rama principal.
Fusión
La ramificación generalmente implica la capacidad de fusionar o integrar posteriormente los cambios en la rama principal. A menudo, los cambios se fusionan con la rama principal, incluso si esta no es la rama principal. Una rama que no está destinada a fusionarse (por ejemplo, porque ha sido relicenciada bajo una licencia incompatible por un tercero o porque intenta cumplir un propósito diferente) generalmente se denomina bifurcación .
Motivaciones para la ramificación
Las ramas permiten desarrollar partes del software en paralelo. [ 2 ] Los proyectos grandes requieren cubrir muchos roles, incluyendo desarrolladores, gestores de compilación y personal de control de calidad . Además, puede ser necesario mantener múltiples versiones en diferentes plataformas de sistemas operativos. Las ramas permiten a los colaboradores aislar los cambios sin desestabilizar el código base, por ejemplo, correcciones de errores, nuevas funcionalidades [ 3 ] e integración de versiones . Estos cambios pueden fusionarse (resincronizarse) posteriormente tras las pruebas.
Las ramas también se pueden usar para implementar la ramificación de proveedores , una estrategia para usar, rastrear y, opcionalmente, modificar el código fuente publicado por terceros externos ("proveedores"). Con este enfoque, bastante común desde la época de CVS , se crea una rama separada para mantener el código proporcionado por el proveedor. Esta rama se actualiza con las nuevas versiones de los proveedores y se fusiona con el código base principal cuando es necesario. [ 4 ]
Rama de desarrollo
Una rama de desarrollo o árbol de desarrollo de un software es una versión que se encuentra en desarrollo y que aún no ha sido lanzada oficialmente . En la comunidad de código abierto , el concepto de lanzamiento suele ser metafórico, ya que cualquiera puede descargar la versión que desee, independientemente de si pertenece a la rama de desarrollo o no. A menudo, la versión que eventualmente se convertirá en la próxima versión principal se denomina rama de desarrollo. Sin embargo, suele haber más de una versión posterior del software en desarrollo simultáneamente.
A menudo, la rama de desarrollo es la rama principal . Algunos sistemas de control de versiones tienen jerga específica para la rama principal de desarrollo. Por ejemplo, en CVS , se llama rama "MAIN". Git usa "master" por defecto, aunque GitHub [ 5 ] [ 6 ] y GitLab cambiaron a "main" después del asesinato de George Floyd .
Sombra o ramas mágicas
En CVSNT , una rama sombra o mágica "oculta" los cambios realizados en la rama ascendente, para facilitar el mantenimiento de pequeños cambios (cvc es un sistema de compilación de paquetes de código abierto que incorpora un sistema de control de versiones para los paquetes producidos por rPath ).
Control de revisiones distribuido
clones de repositorio
En el control de versiones distribuido , se puede copiar y seguir trabajando en todo el repositorio, incluyendo las ramas. Monotone (mtn), Mercurial (hg) y git lo llaman "clonar"; Bazaar lo llama "rama".
En algunos sistemas de control de versiones distribuidos , como Darcs , no se hace distinción entre repositorios y ramas; en estos sistemas, obtener una copia de un repositorio equivale a crear una rama.
Véase también
Referencias
- ↑ Berczuk, Steve; Appleton, Brad (2003). Patrones de gestión de configuración de software: trabajo en equipo eficaz, integración práctica . Addison-Wesley . ISBN 0-20174117-2. Consultado el 24 de mayo de 2007 .
- ↑ Appleton, Brad; Berczuk, Stephen; Cabrera, Ralph; Orenstein, Robert (1998-02-08). "Líneas optimizadas: patrones de ramificación para el desarrollo de software paralelo" ( PDF ) . Hillside . Consultado el 12 de agosto de 2009 .
- ↑ Bailey, Derick (15 de julio de 2009). "Parte 1: Por qué" . Control de código fuente Branch-Per-Feature . Los techies . Recuperado el 12 de agosto de 2009 .
- ↑ Nelson-Smith, Stephen (11 de octubre de 2013). Infraestructura basada en pruebas con Chef: Llevando el desarrollo basado en el comportamiento a la infraestructura como código . O'Reilly Media, Inc. ISBN 978-1-4493-7260-6. Consultado el 26 de mayo de 2025 .
- ↑ Wallen, Jack (22 de septiembre de 2020). "GitHub reemplazará master por main a partir de octubre: lo que los desarrolladores deben hacer ahora" . TechRepublic . Recuperado el 24 de abril de 2022 .
- ↑ Heinze, Carolyn (24 de noviembre de 2020). "Por qué GitHub cambió el nombre de su rama principal a main" . TheServerSide . Consultado el 24 de abril de 2022 .
- Control de versiones