Tutoriel Git : premiers pas avec ce système de gestion de versions

Dé­ve­lop­per des projets logiciels en commun n’est pas une activité propre aux en­tre­prises : dans le secteur open source, plusieurs centaines voire, pour certains projets, plusieurs milliers de vo­lon­taires et bénévoles con­tri­buent à la main­te­nance, à l’op­ti­mi­sa­tion, au dé­ve­lop­pe­ment continu ou à la mo­di­fi­ca­tion d’un programme. Sans un système adapté per­met­tant aux dif­fé­rents dé­ve­lop­peurs d’en­re­gis­trer et de contrôler les nom­breuses mo­di­fi­ca­tions, les projets de ce type seraient dif­fi­ciles à mettre en œuvre.

L’une des solutions les plus ap­pré­ciées pour gérer les versions est le logiciel libre Git, qui est facile à prendre en main et en­tiè­re­ment gratuit. Dans ce tutoriel, nous vous en­seig­nons toutes les bases es­sen­tielles de Git dont vous aurez besoin pour débuter avec ce programme de gestion de versions.

Git est un système de gestion de versions partagé qui fut développé en 2005 par le créateur de Linux Linus Thorvalds et publié sous licence libre GNU-GPLv2. Même si chaque projet dispose d’un ré­per­toire central, la par­ti­cu­la­rité de cet outil réside dans le fait que tous les uti­li­sa­teurs par­ti­ci­pants té­lé­char­gent une copie de travail locale de ce ré­per­toire sur leur appareil. Chacune de ces copies constitue une sau­ve­garde à part entière du ré­per­toire ce qui implique qu’une connexion per­ma­nente au réseau n’est pas né­ces­saire pour le processus de travail sous-jacent. Par ailleurs, les copies servent de sau­ve­garde au cas où le ré­per­toire principal tomberait en panne ou serait endommagé. Les mo­di­fi­ca­tions ef­fec­tuées peuvent être partagées à tout moment avec tous les autres par­ti­ci­pants au réseau et être reprises dans le ré­per­toire si elles sont per­ti­nentes.

Si vous souhaitez apprendre la gestion de logiciels avec Git, vous devrez tout d’abord vous fa­mi­lia­ri­ser avec le logiciel et son interface uti­li­sa­teur. Git est dis­po­nible sous Windows, Unix/Linux et macOS, les versions étant lé­gè­re­ment dif­fé­rentes en termes d’uti­li­sa­tion. Après l’ins­tal­la­tion standard cor­res­pon­dante, vous pourrez contrôler cet outil à l’aide de l’invite de commande ou d’une interface graphique uti­li­sa­teur.

Vous trouverez les fichiers d’ins­tal­la­tion binaires, les notices pour les ins­tal­la­tions du ges­tion­naire de paquets (systèmes Unix) ainsi que les éditions portables prêtes à l’emploi pour les dif­fé­rents systèmes sur le site officiel du projet Git. Té­lé­char­gez sim­ple­ment le paquet souhaité ou utilisez le paquet cor­res­pon­dant dans la gestion des paquets puis suivez les ins­truc­tions de l’assistant d’ins­tal­la­tion. Dans le cas de l’édition portable, il est bien sûr inutile de procéder à une ins­tal­la­tion.

Une fois Git installé sur votre système, vous pouvez utiliser le système de gestion de versions pour gérer vos projets. Comme pour tout autre logiciel, il convient tout d’abord de com­prendre les fonc­tion­na­li­tés et les commandes de base afin de pouvoir tirer profit au maximum de l’ap­pli­ca­tion. Dans le cadre de notre tutoriel Git complet pour les débutants, nous vous ex­pli­quons les prin­ci­pales étapes de mise en place et d’uti­li­sa­tion de Git via l’invite de commande, afin que vous puissiez ensuite créer et gérer votre propre ré­per­toire sans dif­fi­culté.

Le ré­per­toire Git est le ré­per­toire central de tout projet géré et constitue la zone commune à tous les par­ti­ci­pants per­met­tant de régler l’in­té­gra­lité du contrôle des versions. Votre première étape dans Git con­sis­tera donc à créer un tel ré­per­toire principal ou à le cloner (sous la forme d’une copie de travail), dans la mesure où vous vous connectez à un projet dont le dé­ve­lop­pe­ment commun est déjà géré à l’aide de Git.

Si vous souhaitez re­con­fi­gu­rer le contrôle de versions ou si vous venez tout juste d’installer cet outil pour apprendre à utiliser Git, vous devrez tout d’abord créer un ré­per­toire. Pour ce faire, allez dans le ré­per­toire local désiré sur votre appareil à l’aide de « cd » (change directory) :

À cet endroit, saisissez la commande suivante pour créer un ré­per­toire .git :

Si le ré­per­toire Git existe déjà pour votre projet, vous aurez sim­ple­ment besoin de l’adresse Web ou réseau de ce ré­per­toire pour créer une copie de travail sur votre or­di­na­teur avec la commande « git clone » :

Une bonne or­ga­ni­sa­tion du ré­per­toire de travail fait partie des bases es­sen­tielles de Git. Ce ré­per­toire vous permet non seulement de proposer vos propres mo­di­fi­ca­tions et de nouveaux ajouts à un projet qui sont alors repris via commit (« partage »), mais aussi d’acquérir des in­for­ma­tions sur les activités d’autres uti­li­sa­teurs. Vous pouvez vérifier l’actualité de votre copie de travail à l’aide de la commande suivante :

Afin d’ajouter un nouveau fichier à la gestion des versions ou de signaler un fichier édité pour le prochain commit, utilisez la commande « git add » sur ce fichier (il doit se trouver dans le ré­per­toire de travail). Dans notre tutoriel Git, nous avons ajouté à titre d’exemple un document texte intitulé « Test » :

L’ensemble des mo­di­fi­ca­tions que vous avez en­re­gis­trées pour la gestion des versions (de la façon décrite à la section pré­cé­dente) doivent toujours être validées par un commit pour être reprises dans le HEAD. Le HEAD est un type d’index qui renvoie au dernier commit ayant pris effet dans l’en­vi­ron­ne­ment de travail Git actuel (également appelé « branche »). Pour cette étape, la commande est la suivante :

Comme le montre la capture d’écran, après avoir exécuté la commande « git commit », vous obtenez un message ré­ca­pi­tu­la­tif portant sur le commit : dans les crochets pré­cé­dents, vous trouverez d’une part le nom de la branche (branche du projet ; dans le cas présent « master », puisque notre ré­per­toire de travail est également notre ré­per­toire principal), dans lequel les mo­di­fi­ca­tions ont été trans­po­sées, ainsi que la somme de contrôle SHA 1 du commit (ici « c0fdc90 »). Ils sont suivis par un com­men­taire choisi librement (ici « Test ») et par les in­for­ma­tions concrètes sur les mo­di­fi­ca­tions ef­fec­tuées.

Si vous avez repris les mo­di­fi­ca­tions sous la forme d’un commit, vous pouvez éditer le contenu a pos­te­riori ou le reprendre in­té­gra­le­ment. De telles mo­di­fi­ca­tions peuvent par exemple s’avérer né­ces­saires lorsque le commit a été généré trop tôt et que certains fichiers ou certaines mo­di­fi­ca­tions es­sen­tiels ont été oubliés. Dans un tel cas, il convient de mettre à dis­po­si­tion les fichiers nouveaux ou modifiés a pos­te­riori en utilisant « git add » et de répéter l’en­re­gis­tre­ment dans le ré­per­toire principal. Pour ce faire, ajouter l’option --amend à la commande de base :

Si vous souhaitez en revanche reprendre le dernier commit généré, vous devrez utiliser la commande Git suivante :

Cette commande permet de reprendre le dernier commit en­re­gis­tré dans le HEAD. Les fichiers qu’il contient sont ainsi réi­ni­tia­li­sés au statut « mo­di­fi­ca­tions prévues pour le prochain commit ». Si vous souhaitez en revanche supprimer en­tiè­re­ment les données de travail, utilisez la commande suivante à la place de la commande pré­cé­dente :

Les fonc­tion­na­li­tés élé­men­taires de ver­sion­nage sont une bonne raison d’apprendre la gestion de projet avec Git. L’un des gros atouts de ce système open source réside dans le fait qu’il permet d’afficher à tout moment les dernières mo­di­fi­ca­tions ef­fec­tuées dans le ré­per­toire. La commande Git né­ces­saire pour y parvenir est :

La commande log peut par ailleurs être modifiée à l’aide de dif­fé­rents pa­ra­mètres. Certaines options utiles sont listées dans le tableau ci-après :

Jusqu’à présent, nous vous avons montré dans ce tutoriel Git comment en­re­gis­trer les mo­di­fi­ca­tions sous forme de commit dans le HEAD du ré­per­toire local. Toutefois, pour qu’elles soient reprises dans le ré­per­toire principal, il est né­ces­saire de saisir la commande suivante :

Avec ce code, Git transmet au­to­ma­ti­que­ment tous les commits créés, qui jusqu’à présent se trou­vaient uni­que­ment dans la copie de travail, dans le ré­per­toire principal également appelé « master ». Si vous remplacez ce nom dans le code indiqué par une autre branche (branche de projet), les fichiers sont alors di­rec­te­ment envoyés à cet endroit.

Comme de nombreux autres systèmes de contrôle de versions, Git dispose également d’une fonction de balisage per­met­tant de marquer l’im­por­tance de certains points dans l’his­to­rique d’un ré­per­toire. Les balises de ce type sont gé­né­ra­le­ment utilisées pour marquer des versions d’un logiciel, par exemple version 1.0, 2.0, etc., pour qu’elles puissent être con­sul­tées fa­ci­le­ment et à tout moment dans de gros projets. Dans ce cadre, Git supporte deux types de balises :

• les balises annotées (« annotated ») sont en­re­gis­trées comme des objets in­dé­pen­dants dans la base de données, avec la somme de contrôle in­di­vi­duelle, le message de balisage, la date, le nom et l’adresse email de l’auteur de la balise ainsi que la signature GNU Privacy Guard fa­cul­ta­tive (signature GPG).
• les balises non annotées (« light­weight ») fonc­tion­nent ex­clu­si­ve­ment comme des ré­fé­rences à un commit, de façon similaire aux branches. Ce type peut également être utilisé si vous avez uni­que­ment besoin de balises tem­po­raires ou si vous ne souhaitez pas ren­seig­ner des in­for­ma­tions étendues.

Dans Git, vous pouvez créer des balises annotées en utilisant la commande « git tag -a » sur le commit souhaité. Si vous y ajoutez également le paramètre « -m », vous pouvez formuler le message de balisage désiré – entre guil­le­mets droits – di­rec­te­ment dans la ligne de commande. Dans ce tutoriel Git, nous avons généré le commit « Test » que nous avons également associé à une balise avec le message « example tag » :

Pour les balises non annotées, il convient de procéder de façon similaire : utilisez sim­ple­ment la commande de base « git tag » sur le commit souhaité sans autre paramètre. Dans l’exemple de notre tutoriel Git, cela cor­res­pon­drait à la commande suivante :

Dès que les balises pour votre ré­per­toire sont dis­po­nibles, vous pouvez les afficher à l’aide de la commande « git tag » que vous con­nais­sez déjà et des pa­ra­mètres fa­cul­ta­tifs « -l » ou « --list » :

Pour supprimer une balise du ré­per­toire de travail local, utilisez la suite de commandes « git tag -d » sur la balise en question. Pour supprimer notre référence à « Test », il faut donc procéder comme suit :

À l’instar des commits, le transfert des balises dans le ré­per­toire principal s’effectue également ma­nuel­le­ment. Pour ce faire, vous devrez utiliser le nom de la balise et la commande « git push origin ». À la place du nom de la balise, vous pouvez toutefois également ajouter le paramètre « --tags » qui permet d’en­re­gis­trer toutes les balises générées dans le ré­per­toire :

Les branches déjà évoquées dans ce tutoriel Git ne sont en fait rien d’autre que des versions de travail per­son­nelles du ré­per­toire principal, lui-même qualifié de branche portant le nom de « master ». Avec ces branches de travail, Git offre une base idéale pour dé­ve­lop­per des fonc­tion­na­li­tés de façon isolée et les ras­sem­bler uni­que­ment à un moment ultérieur. Cette dernière action est également appelée « fusionner » (en angl. « merge »).

Créer une nouvelle branche n’a rien de compliqué : vous aurez sim­ple­ment besoin de la commande « git branch » et d’y rattacher le nom de la branche souhaitée. Vous pouvez par exemple créer une branche portant le nom « test_branch » de la manière suivante :

Vous pouvez ensuite passer à cette branche à tout moment à l’aide de la commande « git checkout » :

Si vous souhaitez fusionner des branches, vous devrez utiliser la commande « git merge ». À l’aide de « checkout », rendez-vous dans le ré­per­toire devant ac­cueil­lir une nouvelle branche et exécutez à cet endroit la commande précitée en indiquant le nom de la branche à en­re­gis­trer. Notre version de travail « test_branch » peut par exemple être fusionnée avec le ré­per­toire principal de la façon suivante :

Si vous avez fusionné des branches de travail et que vous n’avez plus besoin d’une branche par­ti­cu­lière, vous pouvez la supprimer en toute sim­pli­cité. Pour ce faire, utilisez la suite de commandes « git branch -d » sur la branche de la version qui n’est plus né­ces­saire. L’exemple de notre tutoriel Git « test_branch » peut être supprimé en sai­sis­sant ce qui suit :