stringtranslate.com

Ramificación (control de versiones)

La ramificación , en el control de versiones y la gestión de la configuración de software , es la duplicación de un objeto bajo control de versiones (como un archivo de código fuente o un árbol de directorios ). A partir de entonces, cada objeto puede modificarse por separado y en paralelo para que los objetos sean diferentes. En este contexto, los objetos se denominan ramas . Los usuarios del sistema de control de versiones pueden ramificar cualquier rama.

Las ramas también se conocen como árboles , secuencias 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 secuencia de respaldo .

Trompa

Las ramas hijas son ramas que tienen un padre; una rama sin padre se conoce como tronco o línea principal . [1] El tronco también se conoce a veces vagamente como HEAD, pero propiamente head no se refiere a una rama, sino a la confirmación más reciente en una rama dada, y tanto el tronco como cada rama nombrada tienen su propia cabeza. El tronco generalmente está destinado a ser la base de un proyecto en el que avanza el desarrollo. Si los desarrolladores están trabajando exclusivamente en el tronco, 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 nuevamente en el tronco cuando la rama haya demostrado ser estable y funcionar. Dependiendo del modo de desarrollo y la política de confirmación , el tronco puede contener la versión más estable o menos estable o algo intermedio. Otros términos para el tronco incluyen línea base, línea principal y maestro, aunque en algunos casos se usan con sentidos similares pero distintos; consulte control de versiones § Terminología común . A menudo, el trabajo principal de los desarrolladores se lleva a cabo en el tronco y las versiones estables se ramifican y, ocasionalmente, se fusionan correcciones de errores de las ramas al tronco. Cuando el desarrollo de futuras versiones se realiza en ramas que no son del tronco, generalmente se hace para proyectos que no cambian con frecuencia o donde se espera que un cambio tarde mucho tiempo en desarrollarse hasta que esté listo para incorporarse al tronco.

Fusión

La ramificación generalmente implica la capacidad de fusionar o integrar cambios posteriormente en la rama principal. A menudo, los cambios se fusionan nuevamente en el tronco, incluso si este no es la rama principal. Una rama que no está destinada a fusionarse (por ejemplo, porque un tercero la ha licenciado nuevamente bajo una licencia incompatible o porque intenta cumplir un propósito diferente) generalmente se denomina bifurcación .

Motivaciones para la ramificación

Las ramas permiten que partes del software se desarrollen en paralelo. [2] Los proyectos grandes requieren que se cubran muchos roles, incluidos desarrolladores, administradores de compilación y personal de control de calidad . Además, es posible que se deban mantener múltiples versiones en diferentes plataformas de sistemas operativos. Las ramas permiten a los contribuyentes aislar los cambios sin desestabilizar la base de código, por ejemplo, correcciones de errores, nuevas características [3] e integración de versiones . Estos cambios se pueden fusionar (resincronizar) más tarde después de las pruebas.

Rama de desarrollo

Una rama de desarrollo o árbol de desarrollo de un software es una versión que está en desarrollo y que aún no se ha publicado oficialmente . En la comunidad de código abierto , la noción de lanzamiento suele ser metafórica, ya que cualquiera puede consultar cualquier versión que desee, ya sea que esté en 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, a menudo hay más de una versión posterior del software en desarrollo en un momento dado.

A menudo, la rama de desarrollo es el tronco. Algunos sistemas de control de versiones tienen una jerga específica para la rama de desarrollo principal. Por ejemplo, en CVS , se la llama rama "MAIN". Git usa "master" de manera predeterminada, aunque GitHub [4] [5] y GitLab cambiaron a "main" después del asesinato de George Floyd .

Ramas de sombra o mágicas

En CVSNT , una rama mágica o de sombra "sombrea" los cambios realizados en la rama ascendente, para facilitar el mantenimiento de cambios pequeños (cvc es un sistema de creación de paquetes de código abierto [ cita requerida ] que incorpora un sistema de control de revisión para paquetes producidos por rPath ).

Control de revisión distribuido

Clones de repositorio

En el control de revisión distribuido , se puede copiar todo el repositorio, con sus ramas, y trabajar en él posteriormente. Monotone (mtn), Mercurial (hg) y git lo llaman "clon"; Bazaar lo llama "rama". [ cita requerida ]

En algunos sistemas de control de revisiones distribuidos , como Darcs , no se hace distinción entre repositorios y ramas; en estos sistemas, obtener una copia de un repositorio es equivalente a ramificar.

Véase también

Referencias

  1. ^ 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 .
  2. ^ Appleton, Brad; Berczuk, Stephen; Cabrera, Ralph; Orenstein, Robert (8 de febrero de 1998). "Líneas de flujo: patrones de ramificación para el desarrollo de software paralelo" ( PDF ) . Hillside . Consultado el 12 de agosto de 2009 .
  3. ^ Bailey, Derick (15 de julio de 2009). "Parte 1: Por qué". Control de código fuente Branch-Per-Feature . Los techies . Consultado el 12 de agosto de 2009 .
  4. ^ Wallen, Jack (22 de septiembre de 2020). "GitHub reemplazará master por main a partir de octubre: qué deben hacer los desarrolladores ahora". TechRepublic . Consultado el 24 de abril de 2022 .
  5. ^ Heinze, Carolyn (24 de noviembre de 2020). "Por qué GitHub cambió el nombre de su rama maestra a principal". TheServerSide . Consultado el 24 de abril de 2022 .