Git Guide Número de parte 1: todo lo que necesita saber sobre el directorio .git



Comenzar a usar Git es como visitar un nuevo país cuyo idioma no conoces. Si bien está claro dónde está y hacia dónde ir, todo está bien, pero si se pierde, comienzan los grandes problemas.

Hay toneladas de tutoriales sobre los comandos de Git publicados en Internet, pero en este artículo, el trabajo de Git se examina más profundamente que solo aprender los comandos.

Esta es la primera parte de la guía Git del blog Pierre de Wulf traducida por el equipo de Mail.ru Cloud Solutions

A los nuevos usuarios les resulta difícil sentirse cómodos con Git. Esta es una herramienta poderosa, pero, desafortunadamente, no es muy fácil de aprender. Muchos conceptos nuevos, comandos que realizan diferentes acciones, si el archivo se pasa como parámetro o no, comentarios poco claros ...

Probablemente la única forma de superar todas estas dificultades es aprender un poco más que solo git commit / push, para comprender cómo funciona Git.

Carpeta Git


Cuando crea un nuevo repositorio con el comando git init, Git crea una carpeta mágica, .git. Contiene todo lo que necesitas para que Git funcione. Si desea eliminar Git de su proyecto, pero deja los archivos del proyecto en el disco, simplemente elimine la carpeta .git. Aunque, ¿quién puede necesitar esto?

    ├── HEAD
    ├── branches
    ├── config
    ├── description
    ├── hooks
    │ ├── pre-commit.sample
    │ ├── pre-push.sample
    │ └── ...
    ├── info
    │ └── exclude
    ├── objects
    │ ├── info
    │ └── pack
    └── refs
     ├── heads
     └── tags


Aquí está el contenido de una carpeta .git típica antes de su primer commit:

  1. CABEZA : consideraremos esto más adelante.
  2. config — , , , url , , email . git config, .
  3. description — gitweb .
  4. hooks — , Git. , , / commit/rebase/pull… . push .
  5. info - excluir - los archivos que no desea incluir en el repositorio se describen aquí. La funcionalidad de este archivo es la misma que la del archivo .gitignore, excepto que no se transfiere al repositorio. En la práctica, generalmente .gitignore es suficiente para todas las tareas.

¿Qué hay dentro del commit?


Cada vez que crea un archivo y confirma los cambios, Git archiva el archivo y lo almacena en su estructura de datos. Un objeto archivado se crea con un nombre único y se almacena en la carpeta de objetos.

Antes de examinar la carpeta de objetos, aclaremos qué es commit. Una confirmación es una pepita del estado actual de los archivos en una carpeta de trabajo, pero no solo eso.

De hecho, cuando confirma cambios, Git hace solo dos cosas:

  1. Si el archivo en la carpeta de trabajo no ha cambiado, simplemente agrega el nombre del archivo comprimido (hash) a la instantánea.
  2. Si el archivo en la carpeta de trabajo ha cambiado, lo comprime, lo coloca en la carpeta de objetos y agrega el nombre del archivo comprimido (hash) a la instantánea.

Por supuesto, aquí todo se describe de una manera algo simplificada, sin embargo, esto es suficiente para comprender los procesos en curso.

Tan pronto como se toma una instantánea, también se archiva y se nombra con un hash, luego se coloca en la carpeta de objetos.

├── 4c
│ └── f44f1e3fe4fb7f8aa42138c324f63f5ac85828 // hash
├── 86
│ └── 550c31847e518e1927f95991c949fc14efc711 // hash
├── e6
│ └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391 // hash
├── info // let's ignore that
└── pack // let's ignore that too


Así es como se ve la carpeta de objetos después de crear el archivo_1.txt y confirmarlo. Tenga en cuenta que si el hash de su archivo comienza con "4cf44f1e ...", Git lo guardará con el nombre "f44f1e ..." en una subcarpeta llamada "4c". Por lo tanto, los archivos se distribuirán en 256 subcarpetas y cada uno no tendrá demasiados archivos.

Como puede ver, tenemos tres hashes. Uno para file_1.txt, el segundo para una instantánea tomada en commit. ¿Para qué es el tercero? El tercer hash se crea porque el commit también es un objeto, también se archiva y se coloca en la carpeta de objetos.

Debe recordar que commit consta de cuatro cosas:

  1. El nombre (hash) de la instantánea del directorio de trabajo.
  2. Comentario.
  3. Información sobre quién ejecutó el commit.
  4. El hash del commit padre.

Vea usted mismo lo que sucede si descomprime el archivo de confirmación:

git cat-file -p 4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828

Y esto es lo que verás:

tree 86550c31847e518e1927f95991c949fc14efc711
author Pierre De Wulf 
<test[@gmail.com](mailto:pierredewulf31@gmail.com)> 1455775173 -0500
committer Pierre De Wulf 
<[test@gmail.com](mailto:pierredewulf31@gmail.com)> 1455775173 -0500
commit A

Verá, como se esperaba, el hash de la instantánea, el autor y el comentario de la confirmación. Aquí hay dos cosas importantes:

  1. El hash de la instantánea "86550 ..." también es un objeto y se puede ver en la carpeta de objetos.
  2. Como esta es la primera confirmación, no tiene una confirmación principal.

¿Qué hay realmente en la imagen?

git cat-file -p 86550c31847e518e1927f95991c949fc14efc711
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 file_1.txt

Aquí vemos el objeto que estaba en nuestro almacenamiento de objetos, el único objeto en nuestra imagen.

Branch, tags, HEAD son uno y lo mismo


Ahora entiendes que todo en Git se puede obtener a través del hash correcto. Veamos HEAD ahora. Entonces, ¿qué hay ahí?

cat HEAD
ref: refs/heads/master

No hay hash, y eso tiene sentido, ya que HEAD es un puntero a la parte superior de la rama con la que está trabajando. Si observa el archivo refs / heads / master, verá:

cat refs/heads/master
4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828
 

¿Luce familiar? ¡Naturalmente, es un hash del primer commit! Esto muestra que las etiquetas y las ramas son solo punteros a una confirmación. Al comprender esto, puede eliminar todas las etiquetas que desee, todas las ramas que desee y la confirmación a la que apuntaron permanecerá en su lugar. Lo único, será más difícil acceder a él. Si quieres saber más sobre esto, mira el libro de git .

Último comentario


Después de leerlo, debería ser obvio para usted que todo lo que Git hace es archivar su carpeta de trabajo y ponerla en la carpeta de objetos con información adicional. Si está lo suficientemente familiarizado con Git, entonces tiene control total sobre qué archivos se incluirán en el commit y cuáles no.

Creo que la confirmación no es una instantánea de la carpeta de trabajo, sino una instantánea de los archivos que desea confirmar. ¿Y dónde almacena Git la lista de archivos que desea comprometer? Guarda esta lista en un archivo de índice. No profundizaremos en este tema, si está interesado, puede encontrar más detalles aquí .

Traducido con el soporte de Mail.ru Cloud Solutions .

¿Qué más leer ?

  1. Métodos de almacenamiento en caché simples en GitLab CI: una guía de imágenes .
  2. -Agile .
  3. .


All Articles