C'est quoi Git ? Gestion de versions et GitHub

Git est un logiciel de gestion de versions : il enregistre l'historique complet des modifications d'un projet, permet de revenir à n'importe quel état passé et de travailler à plusieurs sur les mêmes fichiers sans s'écraser. GitHub est un site qui héberge des dépôts Git en ligne et ajoute des outils de travail en équipe. Ce chapitre explique ce que résout un gestionnaire de versions, la différence entre Git et GitHub, où tu croiseras Git au BTS SIO, puis comment installer et configurer Git sur ta machine.

Le problème : projet-final-VRAIMENT-final.zip

Tu as sans doute déjà vécu cette scène. Un projet qui marche, une modification « rapide », et plus rien ne fonctionne. Tu ne sais plus ce que tu as changé. Pour t'en protéger, tu as pris l'habitude de copier ton dossier : projet, projet-v2, projet-final, projet-final-2, projet-VRAIMENT-final. À deux, c'est pire : vous vous envoyez des archives par messagerie, chacun modifie sa copie, et au moment de tout rassembler, il faut comparer les fichiers ligne à ligne en espérant ne rien oublier.

Ces copies posent quatre problèmes :

• Pas de trace. Une copie ne dit ni ce qui a changé, ni pourquoi, ni qui l'a fait.
• Pas de retour fiable. Revenir en arrière, c'est deviner quelle copie était la bonne.
• Pas de travail parallèle. Deux personnes qui modifient le même fichier finissent par écraser le travail de l'autre.
• Pas de sauvegarde sérieuse. Tout vit sur un seul disque ou dans une messagerie.

Un gestionnaire de versions (on dit aussi logiciel de gestion de versions, ou VCS pour Version Control System) règle ces quatre problèmes. Chaque fois que tu le décides, il prend une photo de ton projet, la date, l'attribue à son auteur et la range avec un message qui explique le changement. Ces photos s'appellent des commits, et leur suite forme l'historique du projet.

Ce que Git enregistre vraiment

Un commit n'est pas une copie bête du dossier. Git stocke le contenu de chaque fichier une seule fois : si un fichier n'a pas changé entre deux commits, le second réutilise simplement la version déjà enregistrée. C'est pour cette raison qu'un dépôt de plusieurs années reste léger.

Chaque commit contient :

• l'état de tous les fichiers suivis au moment du commit ;
• le nom et l'adresse e-mail de l'auteur, la date ;
• le message qui décrit le changement ;
• un lien vers le commit précédent, son parent (deux parents pour un commit de fusion).

Git calcule pour chaque commit une empreinte de 40 caractères hexadécimaux, par exemple 0f0c3b3a9e…, avec la fonction de hachage SHA-1. Cette empreinte, qu'on appelle le SHA ou le hash du commit, l'identifie de façon unique : la moindre modification du contenu, du message ou du parent donne une empreinte différente. Dans la pratique, tu n'en tapes que les 7 premiers caractères (0f0c3b3), que Git affiche dans ses résumés.

Centralisé ou distribué

Il existe deux familles de gestionnaires de versions.

Dans un modèle centralisé, comme Subversion (SVN), l'historique vit sur un seul serveur. Chaque développeur n'a sur sa machine que la dernière version des fichiers. Pour enregistrer une modification ou consulter l'historique, il faut joindre le serveur : sans réseau, on ne peut rien faire, et si le serveur meurt sans sauvegarde, l'historique est perdu.

Dans un modèle distribué, comme Git, chaque développeur possède une copie complète du dépôt, historique compris. Tu commites, tu consultes l'historique, tu crées des branches sans connexion. Tu ne te synchronises avec les autres que quand tu le décides, en envoyant tes commits (push) et en récupérant les leurs (pull). Chaque copie est aussi une sauvegarde de tout le projet.

Git a été créé en 2005 par Linus Torvalds pour gérer le code du noyau Linux, puis confié à une communauté de développeurs. Il est libre et gratuit, et c'est aujourd'hui le gestionnaire de versions de l'immense majorité des projets, des petites applications d'entreprise jusqu'à Windows et Android. SVN existe encore dans des entreprises qui ne l'ont pas migré, mais tu n'as pas besoin de l'apprendre.

Quelle différence entre Git et GitHub ?

C'est la confusion la plus fréquente. Git est le logiciel installé sur ta machine : il gère l'historique en local, en ligne de commande ou à travers ton éditeur. GitHub est un service Web, appartenant à Microsoft depuis 2018, qui héberge des dépôts Git sur ses serveurs. Il ajoute ce que Git ne fait pas seul : une interface Web, les pull requests pour relire le code avant de l'intégrer, les issues pour suivre les bugs et les tâches, l'intégration continue avec GitHub Actions, l'hébergement de sites avec GitHub Pages.

Tu peux utiliser Git sans jamais aller sur GitHub. L'inverse est impossible : GitHub ne fait que stocker et afficher des dépôts Git.

On appelle forge un service comme GitHub. Il en existe plusieurs, et tu en croiseras d'autres en stage :

Toutes ces forges hébergent des dépôts Git : les commandes de ce cours sont les mêmes partout. Seuls les noms des fonctions de l'interface changent (GitLab et Gitea : les équivalences).

Le vocabulaire de base

Git au BTS SIO

Git n'est pas une option. Au BTS SIO, il sert dans les deux blocs professionnels.

• Bloc 1, commun aux deux options, évalué à l'E5. La compétence « Travailler en mode projet » demande de planifier, de répartir et de suivre des tâches : les issues, les tableaux de projet et l'historique d'une forge en sont des traces datées. Un historique Git montre aussi qui a fait quoi dans un projet d'équipe (cours sur l'E5).
• Bloc 2 SLAM, évalué à l'E6. Les compétences citent explicitement « Intégrer en continu les versions d'une solution applicative » et « Recueillir, analyser et mettre à jour les informations sur une version d'une solution applicative ». L'environnement technologique exigé par le référentiel (annexe II.E) comprend « un logiciel de gestion de versions et de suivi des problèmes » : concrètement, Git et les issues d'une forge (compétences évaluées à l'E6).
• Option SISR. Les administrateurs versionnent aussi leurs scripts PowerShell et Bash, leurs fichiers de configuration, leurs fichiers Docker Compose et leurs playbooks Ansible. Un script de création de comptes qui casse en production se répare beaucoup plus vite quand on sait ce qui a changé et quand.

Pendant l'heure de réalisation de l'E6 SLAM, tu travailles sur ton propre dépôt : tu crées une branche, tu commites après chaque étape qui marche et tu montres ton historique à la commission (la phase 2 de l'E6). Le chapitre 13 explique comment préparer ce dépôt.

Installer Git

Vérifie d'abord si Git est déjà présent. Ouvre un terminal (PowerShell ou Git Bash sous Windows, Terminal sous macOS et Linux) :

git --version

git version 2.56.0

Le numéro exact importe peu : toute version sortie depuis 2020 convient pour ce cours. Si la commande est inconnue, installe Git :

Configurer Git la première fois

Git signe chaque commit avec un nom et une adresse e-mail. Règle-les une fois pour toutes sur ta machine :

git config --global user.name "Lina Morel"
git config --global user.email "lina.morel@example.com"

--global enregistre le réglage pour tous tes dépôts, dans le fichier ~/.gitconfig de ton compte. Sans --global, le réglage ne vaut que pour le dépôt courant : pratique pour utiliser ton adresse d'entreprise dans le dépôt de ton stage. Utilise l'adresse de ton compte GitHub, sinon GitHub ne relie pas tes commits à ton profil.

Trois autres réglages t'éviteront des surprises :

# Nommer main la branche créée par git init (le nom par défaut de GitHub)
git config --global init.defaultBranch main

# Choisir l'éditeur qui s'ouvre pour les messages longs (ici VS Code, qui attend la fermeture de l'onglet)
git config --global core.editor "code --wait"

# Faire de git pull une récupération suivie d'un rebase plutôt que d'une fusion (expliqué au chapitre 7)
git config --global pull.rebase true

Sans réglage de l'éditeur, Git ouvre souvent Vim. Si tu t'y retrouves coincé, tape Échap, puis :wq et Entrée pour enregistrer et quitter, ou :q! pour quitter sans enregistrer. Si tu préfères Nano, plus simple dans un terminal : git config --global core.editor nano.

Pour relire ta configuration :

git config --global --list

user.name=Lina Morel
user.email=lina.morel@example.com
init.defaultbranch=main
core.editor=code --wait
pull.rebase=true

Et pour savoir d'où vient un réglage (global, local au dépôt ou système) : git config --show-origin user.email.

Exercices

git --version
git config --global user.name "Prénom Nom"
git config --global user.email "adresse@example.com"
git config --global init.defaultBranch main
git config --global --list