¡Empiece en tres minutos! Comprenda los principios de funcionamiento subyacentes de Git en un artículo

1. ¡Empiece en tres minutos! Comprenda el principio de funcionamiento subyacente de Git en un artículo

1.1 Estructura del directorio Git

La esencia de Git es un sistema de archivos (muy importante, recuerde esta oración y comprenda esta oración). Las versiones históricas y los registros de confirmación (commit) de todos los archivos en el directorio de trabajo se guardan en el directorio .git como objetos de archivo.

Primero creemos un directorio vacío llamado git-demo y usemos el comando git init para inicializar el repositorio de Git. Este comando generará un directorio .git en el directorio de trabajo, que se utilizará para guardar las versiones históricas, confirmaciones, bifurcaciones, etiquetas y otra información de todo el historial de archivos en el espacio de trabajo.

$ mkdir git-demo
$ cd git-demo
$ git init

Su estructura de directorios es la siguiente:

1.webp

Nos centraremos en estos directorios más adelante:

  • HEAD: el compromiso correspondiente al estado actual del directorio de trabajo, generalmente el encabezado de la rama actual. HEAD también se puede configurar directamente para un compromiso específico a través del comando git checkout. Esta situación se llama HEAD separado.
  • objetos: este es el directorio que realmente guarda los objetos de Git, incluidos tres tipos de objetos: confirmación, árbol y blob (sabrás cuáles son estos tres tipos de objetos a medida que sigas leyendo)
  • refs: usado para guardar los commits correspondientes a ramas y etiquetas

1.2 Tres objetos principales de Git

Actualmente no hay nada en el directorio Objetos, por lo que creamos un archivo y lo enviamos:

$ git:(master) echo "my project" > README
$ git:(master) mkdir src
$ git:(master) echo "hello world" > src/file1.txt

Agregar y enviar:

$ git:(master) git add .
$ git:(master) git commit -m "init commit"
2.webp

Como puede ver en la impresión, el comando anterior crea un objeto de confirmación que contiene dos archivos. Al observar .git/objectsel directorio, puede ver que se han agregado 5 subdirectorios al directorio 06, 3b, 82, c5, cay cada subdirectorio tiene un archivo con una larga lista de comandos alfanuméricos:

3.webp

¿Qué es esta gran cuerda?

Hay tres tipos de objetos almacenados en el directorio de objetos de Git: Commit, Tree y Blob. Git generará un archivo para el objeto y generará un valor hash SHA-1 basado en la información del archivo como suma de verificación para el contenido del archivo. archivo con esta suma de verificación Los primeros dos caracteres son el subdirectorio del nombre, y los 38 caracteres restantes (suma de verificación) se usan para nombrar el archivo y el archivo se guarda en el subdirectorio.

Puede ver el tipo de objeto mediante el comando git cat-file -t hash value y ver el contenido del objeto mediante el comando git cat-file -p hash value. El valor hash es el nombre del directorio + el nombre del archivo. Si hay No hay ambigüedad. El comando no requiere ingresar el valor hash completo, solo ingrese los primeros dígitos.

Echemos un vistazo uno por uno:

065bca(blob):

4.webp

3b18e(blob):

5.webp

824244(árbol):

6.webp

c5bc98(comprometer):

7.webp

ca96(árbol):

8.webp

Mire la imagen con atención. Después de leerla, casi comprenderá cuáles son los objetos principales comprometidos, blobs y árboles.

Comenzando con el objeto de confirmación (c5bc98), el objeto de confirmación almacena el autor de la confirmación, la información de descripción de la confirmación, la información de la firma y qué objetos de árbol y objetos de blob se incluyen en la confirmación. Como puede verse en la figura anterior, se incluye el objeto de árbol (ca96).

El objeto de árbol puede considerarse como el directorio raíz de todos los archivos relacionados con este envío. Puede ver que el objeto de árbol ca96 contiene un objeto blob (065bca), que es el archivo README, y un objeto de árbol (824244), que es el directorio src. El objeto blob almacena el contenido real.

La relación correspondiente entre estos objetos se muestra en la siguiente figura:

9.webp

1.3. Git Brach 和 día

Ahora veamos el contenido de HEAD. Como se mencionó anteriormente, HEAD almacena las confirmaciones correspondientes al estado actual del directorio de trabajo:

$ git:(master) cat .git/HEAD
ref: refs/heads/master
$ git:(master) cat .git/refs/heads/master
c5bc98b8990bedd7444da537320559e601eba87b

¡c5bc98 es nuestro último compromiso!

master es el nombre de una rama, por lo que la esencia de la rama es un puntero para confirmar

Cortemos una nueva hazaña/trabajo de rama:

10.webp

Verifique los valores de confirmación en refs/heads/master y refs/heads/feat/work:

11.webp

Como se puede ver en su contenido, la rama feat/work no creó ningún archivo de versión nueva y apuntó a la confirmación c5bc98 al igual que master.

Como se puede ver en el experimento anterior, una rama es en realidad solo una aplicación de un objeto de confirmación. Git no almacena una copia para cada rama, por lo que crear una rama en git casi no tiene costo.

A continuación hacemos algunas modificaciones a la rama feat/work y luego enviamos:

$ git:(feat/work) echo "new line" >> src/file1.txt
$ git:(feat/work) echo "do nothing" >> License
$ git:(feat/work) git add .
$ git:(feat/work) git commit -m "some change"
12.webp

Ver el HEAD actual:

13.webp

Puede ver que HEAD apunta a la rama feat/work, y la rama feat/work apunta al compromiso 8a442. El compromiso señalado por la rama maestra no ha cambiado y sigue siendo c5bc98.

Vea el contenido del objeto de confirmación 8a442:

14.webp

Puede ver que la confirmación tiene un campo principal, que apunta a la confirmación anterior c5bc98. También contiene un objeto de árbol (2a9dd):

15.webp

Se puede observar que dado que el archivo README no ha cambiado, todavía apunta al objeto blob 065bca. La licencia es un objeto blob recién creado y src y file1.txt apuntan a la nueva versión del objeto.

Después de agregar esta confirmación, la relación entre varios objetos en Git se muestra a continuación:

16.webp

La etiqueta es similar a la rama y también es un puntero a una confirmación. La diferencia es que después de crear la etiqueta, la confirmación a la que apunta no puede cambiar, pero después de crear la rama, su puntero avanzará después de enviar una nueva confirmación.

Supongo que te gusta

Origin blog.csdn.net/wan212000/article/details/132413933
Recomendado
Clasificación