Git - Conceptos básicos

Sistema de control de versiones

Version Control System (VCS) es un software que ayuda a los desarrolladores de software a trabajar juntos y mantener un historial completo de su trabajo.

A continuación se enumeran las funciones de un VCS:

• Permite a los desarrolladores trabajar simultáneamente.
• No permite sobrescribir los cambios de los demás.
• Mantiene un historial de cada versión.

Los siguientes son los tipos de VCS:

• Sistema de control de versiones centralizado (CVCS).
• Sistema de control de versiones distribuido / descentralizado (DVCS).

En este capítulo, nos concentraremos solo en el sistema de control de versiones distribuido y especialmente en Git. Git cae bajo el sistema de control de versiones distribuido.

Sistema de control de versiones distribuido

El sistema de control de versiones centralizado (CVCS) utiliza un servidor central para almacenar todos los archivos y permite la colaboración en equipo. Pero el mayor inconveniente de CVCS es su único punto de falla, es decir, falla del servidor central. Desafortunadamente, si el servidor central se cae durante una hora, durante esa hora, nadie puede colaborar en absoluto. E incluso en el peor de los casos, si el disco del servidor central se corrompe y no se ha realizado una copia de seguridad adecuada, perderá todo el historial del proyecto. Aquí entra en escena el sistema de control de versiones distribuido (DVCS).

Los clientes de DVCS no solo verifican la última instantánea del directorio, sino que también reflejan completamente el repositorio. Si el servidor deja de funcionar, el repositorio de cualquier cliente se puede volver a copiar en el servidor para restaurarlo. Cada pago es una copia de seguridad completa del repositorio. Git no depende del servidor central y es por eso que puede realizar muchas operaciones cuando está fuera de línea. Puede realizar cambios, crear sucursales, ver registros y realizar otras operaciones cuando no está conectado. Solo necesita una conexión de red para publicar sus cambios y tomar los últimos cambios.

Ventajas de Git

Libre y de código abierto

Git se publica bajo la licencia de código abierto de GPL. Está disponible gratuitamente en Internet. Puede usar Git para administrar proyectos inmobiliarios sin pagar un solo centavo. Como es un código abierto, puede descargar su código fuente y también realizar cambios según sus requisitos.

Rápido y pequeño

Como la mayoría de las operaciones se realizan localmente, ofrece un gran beneficio en términos de velocidad. Git no depende del servidor central; por eso, no es necesario interactuar con el servidor remoto para cada operación. La parte central de Git está escrita en C, lo que evita las sobrecargas de tiempo de ejecución asociadas con otros lenguajes de alto nivel. Aunque Git refleja todo el repositorio, el tamaño de los datos en el lado del cliente es pequeño. Esto ilustra la eficiencia de Git para comprimir y almacenar datos en el lado del cliente.

Copia de seguridad implícita

Las posibilidades de perder datos son muy raras cuando hay varias copias de ellos. Los datos presentes en cualquier lado del cliente reflejan el repositorio, por lo que se pueden usar en caso de una falla o daño del disco.

Seguridad

Git usa una función hash criptográfica común llamada función hash segura (SHA1), para nombrar e identificar objetos dentro de su base de datos. Cada archivo y confirmación se suma y recupera mediante su suma de verificación en el momento del pago. Implica que es imposible cambiar el archivo, la fecha y el mensaje de confirmación y cualquier otro dato de la base de datos de Git sin conocer Git.

Sin necesidad de hardware potente

En el caso de CVCS, el servidor central debe ser lo suficientemente potente como para atender las solicitudes de todo el equipo. Para los equipos más pequeños, no es un problema, pero a medida que aumenta el tamaño del equipo, las limitaciones de hardware del servidor pueden ser un cuello de botella en el rendimiento. En el caso de DVCS, los desarrolladores no interactúan con el servidor a menos que necesiten introducir o extraer cambios. Todo el trabajo pesado ocurre en el lado del cliente, por lo que el hardware del servidor puede ser muy simple.

Ramificación más fácil

CVCS utiliza un mecanismo de copia económico. Si creamos una nueva rama, copiará todos los códigos en la nueva rama, por lo que lleva mucho tiempo y no es eficiente. Además, la eliminación y fusión de ramas en CVCS es complicada y requiere mucho tiempo. Pero la administración de sucursales con Git es muy simple. Solo lleva unos segundos crear, eliminar y fusionar ramas.

Terminologías DVCS

Repositorio local

Cada herramienta VCS proporciona un lugar de trabajo privado como copia de trabajo. Los desarrolladores realizan cambios en su lugar de trabajo privado y, una vez confirmados, estos cambios se convierten en parte del repositorio. Git va un paso más allá al proporcionarles una copia privada de todo el repositorio. Los usuarios pueden realizar muchas operaciones con este repositorio, como agregar archivo, eliminar archivo, renombrar archivo, mover archivo, confirmar cambios y muchas más.

Directorio de trabajo y área de preparación o índice

El directorio de trabajo es el lugar donde se extraen los archivos. En otros CVCS, los desarrolladores generalmente realizan modificaciones y envían sus cambios directamente al repositorio. Pero Git usa una estrategia diferente. Git no rastrea todos y cada uno de los archivos modificados. Siempre que realizas una operación, Git busca los archivos presentes en el área de ensayo. Solo los archivos presentes en el área de preparación se consideran para la confirmación y no todos los archivos modificados.

Veamos el flujo de trabajo básico de Git.

Step 1 - Modificas un archivo del directorio de trabajo.

Step 2 - Agrega estos archivos al área de preparación.

Step 3- Realiza una operación de confirmación que mueve los archivos del área de preparación. Después de la operación de inserción, almacena los cambios de forma permanente en el repositorio de Git.

Suponga que modificó dos archivos, a saber, "sort.c" y "search.c" y desea dos confirmaciones diferentes para cada operación. Puede agregar un archivo en el área de preparación y confirmar. Después de la primera confirmación, repita el mismo procedimiento para otro archivo.

# First commit
[bash]$ git add sort.c

# adds file to the staging area
[bash]$ git commit –m “Added sort operation”

# Second commit
[bash]$ git add search.c

# adds file to the staging area
[bash]$ git commit –m “Added search operation”

Manchas

Blob significa Binario Large Object. Cada versión de un archivo está representada por blob. Un blob contiene los datos del archivo, pero no contiene metadatos sobre el archivo. Es un archivo binario, y en la base de datos de Git, se denomina hash SHA1 de ese archivo. En Git, los archivos no se identifican con nombres. Todo está dirigido al contenido.

Árboles

El árbol es un objeto que representa un directorio. Contiene blobs y otros subdirectorios. Un árbol es un archivo binario que almacena referencias a blobs y árboles que también se denominanSHA1 hash del objeto árbol.

Compromete

Commit contiene el estado actual del repositorio. Una confirmación también es nombrada porSHA1picadillo. Puede considerar un objeto de confirmación como un nodo de la lista vinculada. Cada objeto de confirmación tiene un puntero al objeto de confirmación principal. Desde una confirmación determinada, puede retroceder mirando el puntero principal para ver el historial de la confirmación. Si una confirmación tiene varias confirmaciones principales, esa confirmación en particular se ha creado fusionando dos ramas.

Ramas

Las ramas se utilizan para crear otra línea de desarrollo. De forma predeterminada, Git tiene una rama maestra, que es la misma que la troncal en Subversion. Por lo general, se crea una rama para trabajar en una nueva característica. Una vez que se completa la función, se vuelve a fusionar con la rama maestra y eliminamos la rama. Cada rama es referenciada por HEAD, que apunta a la última confirmación en la rama. Siempre que realiza una confirmación, HEAD se actualiza con la última confirmación.

Etiquetas

La etiqueta asigna un nombre significativo con una versión específica en el repositorio. Las etiquetas son muy similares a las ramas, pero la diferencia es que las etiquetas son inmutables. Significa que la etiqueta es una rama que nadie tiene la intención de modificar. Una vez que se crea una etiqueta para una confirmación en particular, incluso si crea una nueva confirmación, no se actualizará. Por lo general, los desarrolladores crean etiquetas para lanzamientos de productos.

Clon

La operación de clonación crea la instancia del repositorio. La operación de clonación no solo comprueba la copia de trabajo, sino que también refleja el repositorio completo. Los usuarios pueden realizar muchas operaciones con este repositorio local. El único momento en que se involucra la red es cuando se sincronizan las instancias del repositorio.

Halar

La operación de extracción copia los cambios de una instancia de repositorio remoto a una local. La operación de extracción se utiliza para la sincronización entre dos instancias de repositorio. Es lo mismo que la operación de actualización en Subversion.

empujar

La operación de inserción copia los cambios de una instancia de repositorio local a una remota. Esto se utiliza para almacenar los cambios de forma permanente en el repositorio de Git. Es lo mismo que la operación de confirmación en Subversion.

CABEZA

HEAD es un puntero, que siempre apunta a la última confirmación en la rama. Siempre que realiza una confirmación, HEAD se actualiza con la última confirmación. Las cabezas de las ramas se almacenan en.git/refs/heads/ directorio.

[CentOS]$ ls -1 .git/refs/heads/
master

[CentOS]$ cat .git/refs/heads/master
570837e7d58fa4bccd86cb575d884502188b0c49

Revisión

Revisión representa la versión del código fuente. Las revisiones en Git están representadas por confirmaciones. Estas confirmaciones se identifican medianteSHA1 hash seguros.

URL

URL representa la ubicación del repositorio de Git. La URL de Git se almacena en el archivo de configuración.

[[email protected] tom_repo]$ pwd
/home/tom/tom_repo

[[email protected] tom_repo]$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = [email protected]:project.git
fetch = +refs/heads/*:refs/remotes/origin/*