Playlist « Les concepts clés de Git » : https://www.youtube.com/playlist?list=PLPoAfTkDs_JbMPY-BXzud0aMhKKhcstRc
Si tu veux bien comprendre les opérations que tu réalises avec Git, tu dois comprendre les étapes par lesquelles transitent tes fichiers pour gérer tes versions, et par conséquent tu dois connaître une partie de l’architecture de Git, à commencer par les zones.
Je sais, c’est terrible, il faut que tu apprennes l’outil si tu veux travailler finement et intelligemment, et lire la doc’, bah c’est chiant ! Heureusement que je suis là pour t’expliquer tout ça !😄
Comme je te le disais, Git propose une gestion très fine du cycle de vie des fichiers. Tu trouveras peut être ça plus compliqué que dans des outils comme Subversion, avec plus d’opérations à réaliser tout ça, tout ça. Mais en vrai, tu peux faire aussi peu d’opérations en Git ce qui te produira un historique tout aussi moisi.
Quoi qu’il en soit, l’objectif de Git, c’est d’élargir le potentiel que présentaient ces outils et de te permettre d’effectuer aussi bien des opérations chirurgicales que des opérations classiques, et tant qu’à faire, le plus rapidement possible.
Les zones de Git vont te servir à ça, c’est-à-dire à construire tes commits et préparer, puis partager ton historique. Selon les zones que tu utilises, l’état des fichiers change pour passer d’un état de création à un état validé, enregistré dans Git.
5 zones
Il existe 5 zones en tout qu’on découpe virtuellement en fonction de leur fréquence d’utilisation, ce qui va également me faciliter leur explication.
Les 3 zones que je qualifie de « principales » sont :
la copie de travail ;
l’index, dont le nom a varié dans le temps et qu’on retrouve parfois sous les noms de stage, staging area ou encore cache ;
enfin, le dépôt local ou local repository en anglais.
On a déjà vu ce qu’est la copie de travail, c’est l’endroit où tu réalises ton travail.
L’index est une zone tampon qui va te servir à affiner ton prototype de commit jusqu’à sa validation. Il est hyper précieux, car c’est grâce à lui que tu peux choisir les fichiers ou parties de fichiers que tu souhaites intégrer dans ton prochain commit.
Le dépôt local est en quelque sorte ta base de données locale puisqu’il stocke les commits et les autres informations qui sont utiles à ta gestion de versions.
Tu l’as certainement compris : ces 3 zones « principales » sont celles que tu utilises tout le temps puisque c’est à travers elles que tu construis ton historique.
On utilise plus occasionnellement les 2 autres zones. On y trouve
le stash, qu’on apelle aussi « remise » en français, et qui te permet de mettre de côté un travail que tu aurais commencé pour en réaliser un autre, souvent plus urgent ;
enfin on a le dépôt distant, qui te sert à partager ton historique de commits ou à le synchroniser avec d’éventuels membres d’une équipe. La synchronisation s’effectue donc entre ton dépôt local et un dépôt distant.
On va commencer par voir dans le détail ces 3 zones principales avec les étapes de construction d’un historique.
Les étapes d’un commit à travers les zones
On commence avec les étapes de création d’un commit à travers notre copie de travail, notre index et jusqu’à notre dépôt local.
Un commit stocke des informations liées à des fichiers qui sont créés, modifiés ou supprimés.
Pour préparer un commit tu commences donc dans ta copie de travail, par exemple ici tu créés et tu mets à jour les fichiers « A », « B » et « C ». Tu prévois de tous les intégrer dans ton commit. Tu les ajoutes donc à l’index, ce qui prépare ce qu’on appelle des instantanés, des sortes de photos des fichiers. Tu te rends alors compte que les fichiers B et C traitent en fait d’autres sujets que « A », et comme tu veux créer des commits qui ont du sens, tu décides de les retirer de l’index. Tu modifies « C », ce qui est représenté par par le « C’ » à l’écran. Et vu qu’il traite maintenant du même sujet que A, tu le rajoutes à l’index. Le travail à l’air satisfaisant, tu valides donc et crées le commit.
Si jamais le commit mérite d’autres mises à jour, il faudra que tu le défasses en gardant le travail qu’il contenait, donc en revenant soit à l’état des fichiers indexés, soit à l’état de la copie de travail. Dans les 2 cas, tu oublies le commit sans perdre ton travail avec l’optique de créer un autre commit à la place.
Enfin, tu peux aussi vouloir simplement oublier tout le travail représenté par le commit, ce qui veut dire défaire ton travail dans les 3 zones.
Note que j’ai bien parlé d’oublier le commit. J’insiste là-dessus car Git ne supprime pas immédiatement les objets dans sa base de données, il ne fait que les déréférencer, mais ça, on reparlera plus tard.
…
Envie de commenter ? Fais-le directement sur YouTube !