Ramas de Git, por qué y cómo usarlas
Casi todos los sistemas de control de versiones admiten alguna forma de ramificación. El uso de ramas significa que puede separarse de la línea principal de desarrollo y continuar trabajando sin afectar la línea principal. En muchos sistemas de control de versiones, este es un proceso costoso, que a menudo requiere la creación de una copia completa del directorio del código fuente, lo que puede llevar mucho tiempo en proyectos grandes.
Algunas personas llaman al modelo de ramificación de Git la "característica principal" que distingue a Git de otros sistemas de control de versiones.
Lo especial de Git es que es increíblemente liviano, puedes crear nuevas ramas casi instantáneamente y cambiar entre ramas con la misma rapidez. La función de ramificación de Git es tan liviana que puedes crear nuevas ramas casi instantáneamente y cambiar entre ramas con la misma rapidez. A diferencia de muchos otros sistemas de control de versiones, Git fomenta la bifurcación y fusión de ramas frecuentes en su flujo de trabajo, incluso varias veces al día. Una vez que comprenda el concepto de ramificación y se sienta cómodo con él, comprenderá por qué Git es una herramienta tan poderosa y única que realmente puede cambiar la forma en que se desarrolla.
Para comprender cómo funcionan las ramas de Git, debemos revisar cómo Git almacena los datos. Quizás recuerdes del Capítulo 1 que Git no almacena diferencias o cambios de archivos, sino más bien una serie de instantáneas de archivos.
Cuando realizas una confirmación en Git, guardas un objeto de confirmación que contiene un puntero a una instantánea del contenido de la prueba, información sobre el autor de la confirmación, otras dependencias y cero o múltiples punteros para confirmar a los padres: la primera confirmación no tiene ancestros directos, una confirmación normal tiene solo un ancestro, mientras que una confirmación formada al fusionar dos o más ramas tiene más de un ancestro, una confirmación formada al fusionar dos o más ramas tiene más de un ancestro La confirmación resultante tiene múltiples ancestros.
Por intuición, digamos que hay tres archivos en el directorio de trabajo y estamos listos para enviarlos después de la preparación. La operación de preparación calcula una suma de verificación para cada archivo (la cadena hash SHA-1 mencionada en el Capítulo 1) y luego guarda una instantánea de la versión actual del archivo en el repositorio de Git (Git usa objetos de tipo blob para almacenar estas instantáneas) y agregue la suma de verificación al área de preparación:
$ git add README test.rb LICENCIA$ git commit -m 'compromiso inicial de mi proyecto'
Cuando Cuando creas un nuevo compromiso usando "git commit", Git calcula una suma de verificación para cada subdirectorio (en este caso, el directorio raíz del proyecto) y luego guarda estos directorios como un árbol en el repositorio de Git. Luego, Git crea un objeto de confirmación que contiene no solo la información de confirmación sino también un puntero al objeto del árbol (la raíz del proyecto) para que el contenido de la instantánea se pueda recrear si es necesario en el futuro.
Ahora, hay cinco objetos en el repositorio de Git: tres objetos blob, que representan el contenido de la instantánea del archivo; un objeto de árbol, que registra el contenido del árbol de directorios y el índice del objeto blob de cada archivo. el árbol; un objeto de confirmación que contiene el índice del objeto del árbol (raíz) y otros metadatos sobre la confirmación. Conceptualmente, los datos y las relaciones entre varios objetos en el repositorio se muestran en la Figura 3-1:
Figura 3-1 de un único objeto de envío en el repositorio
Después. realiza algunos cambios y se confirma nuevamente, esta vez el objeto de confirmación contendrá un puntero al último objeto de confirmación (el objeto principal en la imagen a continuación). Después de dos envíos, el historial del repositorio será como se muestra en la Figura 3-2:
Figura 3-2 Vínculos entre múltiples envíos
Rama: en Git Una rama es esencialmente. solo un puntero mutable a un objeto de confirmación, y Git usa master como nombre de la rama de forma predeterminada. Después de algunas confirmaciones, tendrá una rama maestra que apunta a la última confirmación, que avanzará automáticamente después de cada confirmación.
Figura 3-3. La bifurcación en realidad está revisando el historial de envíos.
Entonces, ¿cómo crea Git una nueva rama? La respuesta es simple: crea un nuevo puntero de rama.
Por ejemplo, para crear una nueva rama para realizar pruebas, puede usar el comando git branch:
$ git branch testing
Esto creará un nuevo puntero de rama a la confirmación actual ( ver Figura 3-4).
Figura 3-4. Múltiples punteros de rama que apuntan al historial de confirmaciones.
Entonces, ¿cómo sabe Git en qué rama estás trabajando actualmente? La respuesta es simple: guarda un puntero especial llamado HEAD. Tenga en cuenta que esto es muy diferente del concepto de HEAD en otros sistemas de control de versiones como Subversion o CVS. En Git, HEAD es un puntero a la rama local en la que estás trabajando (piensa en HEAD como un alias de la rama actual). En Git, es un puntero a la sucursal local en la que estás trabajando. La ejecución del comando git branch? simplemente crea una nueva rama pero no cambia automáticamente a ella, por lo que en este caso todavía estamos trabajando en la rama maestra (consulte la Figura 3-5).
Figura 3-5. HEAD apunta a la rama actual
Para cambiar a otra rama, puedes ejecutar el comando git checkout? Ahora cambiamos a la rama de prueba recién creada:
$ git checkout testing
De esta manera HEAD apunta a la rama de prueba (ver Figura 3-6).
Figura 3-6. HEAD apunta a la nueva rama al cambiar de rama
¿Cuáles son los beneficios de esta implementación? Bueno, vale la pena comprometerse nuevamente:
$ vim test.rb$ git commit -a -m 'hizo un cambio'
La Figura 3-7 muestra el resultado de la confirmación.
Figura 3-7. Después de cada confirmación, HEAD avanzará con la rama.
Lo que es muy interesante es que la rama de prueba ahora ha avanzado un espacio y la rama principal. Sigue apuntando al mismo objeto de confirmación que tenía en su "git checkout" original.
Ahora volvamos a la rama maestra y veamos cómo se ve. Ahora volvamos a la rama master:
$ git checkout master
La Figura 3-8 muestra los resultados.
Figura 3-8. HEAD se mueve a otra rama después del pago
Este comando hace dos cosas. Mueve el puntero HEAD de regreso a la rama maestra y reemplaza los archivos en el directorio de trabajo con el contenido de la instantánea a la que apunta la rama maestra. En otras palabras, las modificaciones que vas a realizar ahora serán de una versión anterior del proyecto. El objetivo principal de esto es deshacer temporalmente los cambios realizados en la rama de prueba para que pueda moverse en la otra dirección.