Get best of the week

Git Guide Partie numéro 1: tout ce que vous devez savoir sur le répertoire .git



Commencer Ă  utiliser Git, c'est comme visiter un nouveau pays dont vous ne connaissez pas la langue. S'il est clair oĂč vous ĂȘtes et oĂč aller, tout va bien, mais si vous vous perdez, de gros problĂšmes commencent.

Il existe des tonnes de didacticiels sur les commandes Git publiés sur Internet, mais dans cet article, le travail de Git est examiné plus en profondeur que d'apprendre les commandes.

Ceci est la premiĂšre partie du guide Git du blog Pierre de Wulf traduit par l'Ă©quipe Mail.ru Cloud Solutions . 

Les nouveaux utilisateurs ont du mal à se familiariser avec Git. Il s'agit d'un outil puissant, mais malheureusement pas trÚs facile à apprendre. Beaucoup de nouveaux concepts, des commandes qui effectuent différentes actions, si le fichier est passé en paramÚtre ou non, des commentaires peu clairs ...

La seule façon de surmonter toutes ces difficultés est probablement d'apprendre un peu plus que git commit / push, pour comprendre comment Git fonctionne.

Dossier .Git


Lorsque vous créez un nouveau référentiel avec la commande git init, Git crée un dossier magique, .git. Il contient tout ce dont vous avez besoin pour que Git fonctionne. Si vous souhaitez supprimer Git de votre projet, mais laissez les fichiers du projet sur le disque, supprimez simplement le dossier .git. Mais qui pourrait en avoir besoin?

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


Voici le contenu d'un dossier .git typique avant votre premier commit:

  1. HEAD - nous y réfléchirons plus tard.
  2. config — , , , url , , email . git config, .
  3. description — gitweb .
  4. hooks — , Git. , , / commit/rebase/pull
 . push .
  5. info - exclude - les fichiers que vous ne souhaitez pas inclure dans le rĂ©fĂ©rentiel sont dĂ©crits ici. La fonctionnalitĂ© de ce fichier est la mĂȘme que celle du fichier .gitignore, sauf qu'il n'est pas transfĂ©rĂ© dans le rĂ©fĂ©rentiel. Dans la pratique, .gitignore est gĂ©nĂ©ralement suffisant pour toutes les tĂąches.

Que contient le commit?


Chaque fois que vous créez un fichier et validez des modifications, Git archive le fichier et le stocke dans sa structure de données. Un objet archivé est créé avec un nom unique et stocké dans le dossier des objets.

Avant d'examiner le dossier d'objets, clarifions ce qu'est la validation. Un commit est un nugget de l'Ă©tat actuel des fichiers dans un dossier de travail, mais pas seulement.

En fait, lorsque vous validez des modifications, Git ne fait que deux choses:

  1. Si le fichier dans le dossier de travail n'a pas changé, il ajoute simplement le nom du fichier compressé (hachage) à l'instantané.
  2. Si le fichier du dossier de travail a changé, il le comprime, le place dans le dossier des objets et ajoute le nom du fichier compressé (hachage) à l'instantané.

Bien sûr, ici tout est décrit d'une maniÚre quelque peu simplifiée, cependant, cela suffit pour comprendre les processus en cours.

DÚs qu'un instantané est pris, il est également archivé et nommé avec un hachage, puis placé dans le dossier des objets.

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


Voici à quoi ressemble le dossier d'objets aprÚs avoir créé file_1.txt et l'avoir validé. Veuillez noter que si le hachage de votre fichier commence par «4cf44f1e ...», Git l'enregistrera sous le nom «f44f1e ...» dans un sous-dossier nommé «4c». Ainsi, les fichiers seront disposés dans 256 sous-dossiers et chacun n'aura pas trop de fichiers.

Comme vous pouvez le voir, nous avons trois hachages. Un pour file_1.txt, le second pour un instantanĂ© pris lors de la validation. À quoi sert le troisiĂšme? Le troisiĂšme hachage est crĂ©Ă© car le commit est Ă©galement un objet, il est Ă©galement archivĂ© et placĂ© dans le dossier des objets.

Vous devez vous rappeler que la validation se compose de quatre choses:

  1. Le nom (hachage) de l'instantané du répertoire de travail.
  2. Commentaire.
  3. Informations sur qui a exécuté le commit.
  4. Le hachage du commit parent.

Voyez par vous-mĂȘme ce qui se passe si vous dĂ©compressez le fichier de validation:

git cat-file -p 4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828

Et voici ce que vous verrez:

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

Vous voyez, comme prévu, le hachage de l'instantané, l'auteur et le commentaire du commit. Deux choses sont importantes ici:

  1. Le hachage de l'instantanĂ© "86550 ..." est Ă©galement un objet et peut ĂȘtre vu dans le dossier des objets.
  2. Comme il s'agit du premier commit, il n'a pas de commit parent.

Qu'est-ce qui est vraiment dans l'image?

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

Ici, nous voyons l'objet qui Ă©tait dans notre stockage d'objets, le seul objet dans notre image.

Branche, tags, HEAD sont une seule et mĂȘme chose


Vous comprenez maintenant que tout dans Git peut ĂȘtre obtenu via le hachage correct. Regardons maintenant HEAD. Alors qu'y a-t-il?

cat HEAD
ref: refs/heads/master

Il n'y a pas de hachage, et cela a du sens, car HEAD est un pointeur vers le haut de la branche avec laquelle vous travaillez. Si vous regardez le fichier refs / heads / master, vous verrez:

cat refs/heads/master
4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828
 

Ça vous semble familier? Naturellement, c'est un hachage du premier commit! Cela montre que les balises et les branches ne sont que des pointeurs vers une validation. En comprenant cela, vous pouvez supprimer toutes les balises que vous souhaitez, toutes les branches que vous souhaitez et la validation vers laquelle elles pointaient restera en place. La seule chose, il sera plus difficile d'y accĂ©der. Si vous voulez en savoir plus Ă  ce sujet, consultez le git book .

Dernier commentaire


AprĂšs l'avoir lu, il devrait devenir Ă©vident pour vous que tout ce que fait Git est d'archiver votre dossier de travail et de le placer dans le dossier des objets avec des informations supplĂ©mentaires. Si vous ĂȘtes assez familier avec Git, vous avez un contrĂŽle total sur les fichiers qui seront inclus dans la validation et ceux qui ne le seront pas.

Je crois que la validation n'est pas un instantanĂ© du dossier de travail, mais un instantanĂ© des fichiers que vous souhaitez valider. Et oĂč Git stocke-t-il la liste des fichiers que vous souhaitez valider? Il enregistre cette liste dans un fichier d'index. Nous ne nous pencherons pas en profondeur sur cette question, si vous ĂȘtes intĂ©ressĂ©, plus de dĂ©tails peuvent ĂȘtre trouvĂ©s ici .

Traduit avec le support de Mail.ru Cloud Solutions .

Quoi d'autre Ă  lire :

  1. MĂ©thodes de mise en cache simples dans GitLab CI: un guide d'images .
  2. -Agile .
  3. .

More articles:


All Articles