Bon jusque là rien de bien fou, je t’ai raconté des généralités sur des choses qui te paraissent peut être évidentes. Après, ça ne fait jamais de mal de prendre du recul et de repenser à nos attentes quand il s’agit d’utiliser des outils.

Il est temps que je rentre un peu plus dans le vif du sujet, en parlant justement de Git et de ce qu’il nous apporte d’utile.

Avec Git et les outils évolués de gestion de versions on se retrouve confronté à autre chose que 3 actions classiques en mode « commit, pull, push ». Ça implique donc, en plus de l’architecture, de connaître le vocabulaire propre à l’outil. C’est un peu comme quand tu codes, si tu n’apprends pas le langage, ne t’attends pas à faire des miracles, même si certains trucs comme WinDev et WebDev te promettent le contraire.

Alors je ne vais pas te faire le tour du glossaire global de Git, d'ailleurs tu as la commande git help glossary pour ça, mais je vais te donner les mots clés qui devraient t’être utiles pour comprendre ce qui se passe.

Un peu de vocabulaire…

Allez, on attaque avec le premier terme : la copie de travail, ou “working directory” en anglais. Celui-la n’est pas le plus dur. J’imagine que tu as compris qu’il s’agit de l’état actuel sur le disque des dossiers et fichiers, donc ton espace de travail au sein du projet.

En face, tu as le dépôt. C’est grosso-modo la destination de ton travail dans Git et qui gèrera l’ensemble de tes versions pour un même projet, localement ou sur un serveur.

Dans cette copie de travail, lorsque tu fais une série de modifications sur des fichiers et que tu souhaites les enregistrer dans Git, tu créés alors une version, ou révision, qu’on appelle aussi plus couramment un commit. 

Il s’agit donc d’une soumission unique, idéalement thématique et atomique et pour laquelle Git créera un identifiant unique, le SHA-1, dont on reparlera un peu plus tard.

Quand tu as réalisé plusieurs commits, tu te retrouves avec une succession de versions qui représente l’historique de ton projet, autrement appelé le log.

Et pour marquer l’emplacement duquel Git doit partir pour créer une nouvelle version, il utilise une référence nommée HEAD. C’est généralement le dernier commit en date dans l’historique de référence actuel. 

Tu peux voir ça comme ton véhicule sur un trajet à parcourir, car HEAD avancera toujours avec toi. Donc dans Git, HEAD marque l’emplacement où tu te situes, c’est-à-dire qu’il fait directement ou indirectement référence à un commit. Le terme est plutôt bien choisi, car on ne va nulle part sans sa tête… ou alors pas très loin avant que tout s’arrête…

Pour isoler un ensemble de commits sur un thème ou simplement pour travailler plus facilement en équipe, on utilise les branches. 

La branche de référence dans un dépôt, c’est la branche master, avec un « m » minuscule. C’est aussi celle qui est créée par défaut par Git. 

Après, on peut faire ce qu’on veut avec les branches, les créer depuis où on veut, avec la profondeur qu’on veut, et sans contrainte.

Enfin, quand tu as terminé un travail isolé et que tu souhaites le mêler à un sur-ensemble, tu vas devoir fusionner les branches concernées, ou faire un merge, en terminologie Git.

Ça va donc venir réconcilier des travaux de plusieurs branches pour te fournir un résultat consolidé.

Voilà pour la base du vocabulaire utile à Git. On verra d’autres termes utiles au fil de l’eau, car pour certains j’ai besoin de plus de contexte pour que tu comprennes bien. Allez, il est temps que je te montre le fonctionnement de Git, à commencer par son architecture.