Arc 1 Quête 01

La Guilde des Archivistes

Installation et configuration de Git

Introduction

Le vent siffle entre les tours de la Citadelle du Savoir lorsque tu franchis les lourdes portes de la Guilde des Archivistes. Ici, des scribes s'affairent à conserver la mémoire du royaume tout entier - chaque décret royal, chaque traité de paix, chaque plan de bataille. Sans eux, l'histoire serait perdue à jamais.

Un vieil homme à la barbe argentée s'approche de toi. Ses yeux pétillent de malice derrière ses lunettes rondes. C'est le Maître Archiviste.

« Bienvenue, jeune recrue. Je suis le Maître Archiviste, gardien de l'histoire du royaume. Tu arrives à point nommé, car nous avons un grave problème… Nos scribes perdent leur travail, écrasent les parchemins des autres, et personne ne sait plus qui a modifié quoi. Il nous faut un nouveau système d'archivage. Et toi, tu vas apprendre à le maîtriser. »

Le problème : travailler sans versioning

Avant de comprendre la solution, il faut comprendre le problème. Voici ce qui se passe quand on travaille sans système de versioning :

Le chaos des noms de fichiers

Tu connais sûrement cette situation :

rapport_final.txt
rapport_final_v2.txt
rapport_final_v2_corrigé.txt
rapport_FINAL_VRAIMENT_FINAL.txt
rapport_FINAL_VRAIMENT_FINAL_2.txt
rapport_FINAL_OK_CELUI_LA.txt

Lequel est le bon ? Personne ne le sait. Même pas la personne qui les a créés.

Le travail écrasé

Imagine : deux scribes, Aldric et Bérénice, travaillent sur le même parchemin. Aldric fait ses modifications le matin et sauvegarde. Bérénice, qui avait ouvert le parchemin la veille au soir, fait ses propres modifications l'après-midi et sauvegarde aussi. Résultat : tout le travail d'Aldric a disparu, écrasé sans avertissement. Aldric passe une très mauvaise journée.

Le mystère des modifications

« Ça marchait hier ! Qu'est-ce qui a changé ? »

Quelqu'un a modifié quelque chose. Mais qui ? Quand ? Et surtout, pourquoi ? Impossible de le savoir. On perd des heures à chercher, et parfois on ne retrouve jamais la version qui fonctionnait.

La solution : le versioning

Le Maître Archiviste a trouvé la solution. Au lieu de sauvegarder bêtement par-dessus l'ancien fichier, on va enregistrer chaque modification avec quatre informations essentielles :

  • Qui a fait la modification
  • Quand elle a été faite
  • Quoi exactement a changé (pas juste "j'ai modifié le fichier", mais quelles lignes précisément)
  • Pourquoi - un petit message qui explique la raison du changement

Avec le versioning, tu peux revenir en arrière à tout moment, voir l'historique complet de toutes les modifications, et plusieurs personnes peuvent travailler en même temps sans s'écraser mutuellement.

Git : l'outil des Archivistes modernes

Le système que tu vas apprendre s'appelle Git. C'est l'outil de versioning le plus utilisé au monde. Mais il n'est pas le premier - d'autres ont essayé avant lui.

Avant Git : les anciens systèmes

Le besoin de suivre les modifications de fichiers ne date pas d'hier. Plusieurs outils ont existé avant Git :

  • RCS (1982) - Un des premiers systèmes de versioning. Il ne gérait qu'un seul fichier à la fois - impossible de travailler sur un projet entier.
  • CVS (1990) - Le premier outil à gérer plusieurs fichiers ensemble. Mais il reposait sur un serveur central : si le serveur tombait, plus personne ne pouvait travailler.
  • SVN / Subversion (2000) - Une amélioration de CVS, plus fiable et plus rapide. Très populaire pendant des années, mais toujours centralisé : chaque opération nécessitait une connexion au serveur.
  • Mercurial (2005) - Créé la même année que Git, avec la même philosophie distribuée. Un bon outil, mais Git l'a progressivement dépassé en popularité.

Le problème commun de ces outils ? Soit ils étaient trop limités, soit ils dépendaient d'un serveur central, soit ils étaient trop lents pour les très gros projets.

L'arrivée de Git

  • 2005 - Linus Torvalds (le créateur de Linux) gère le code source du noyau Linux - un projet avec des milliers de développeurs et des millions de lignes de code. Les outils existants ne tiennent pas la charge. Alors il crée le sien en quelques semaines : Git.
  • Distribué - Contrairement aux anciens systèmes, Git est distribué : chaque personne qui travaille sur un projet possède une copie complète de tout l'historique. Pas besoin d'un serveur central pour consulter l'histoire du projet.
  • Rapide - Git a été conçu pour être extrêmement rapide, même sur des projets gigantesques. Le noyau Linux lui-même - avec plus de 30 ans d'historique et des millions de lignes - est géré avec Git.
  • Aujourd'hui - Git est gratuit, open source, et utilisé par pratiquement tous les développeurs de la planète. Des plateformes comme GitHub, GitLab et Bitbucket sont construites autour de Git.

Oui, Git a beaucoup de commandes et peut sembler complexe au début. Mais c'est justement cette puissance qui lui permet de gérer aussi bien un petit projet personnel qu'un monstre comme le noyau Linux. Et dans la pratique, une poignée de commandes suffit pour 90% du travail quotidien.

Git n'est pas réservé aux développeurs ! Il peut servir pour tout projet composé de fichiers texte : documentation, fichiers de configuration, sites web, etc.

Installation de Git

Avant de commencer à utiliser Git, il faut l'installer sur ta machine. Voici les instructions selon ton système d'exploitation.

Windows

  1. Rends-toi sur git-scm.com et télécharge l'installateur.
  2. Lance l'installateur et suis les étapes (les options par défaut conviennent très bien).
  3. L'installation inclut Git Bash, un terminal qui te permettra d'utiliser les commandes Git.
  4. Pour vérifier : ouvre Git Bash et tape git --version.

Linux

Ouvre un terminal et utilise le gestionnaire de paquets de ta distribution :

# Debian, Ubuntu, Mint…
sudo apt install git

# Fedora, RHEL, CentOS…
sudo dnf install git

# Arch Linux
sudo pacman -S git

Pour vérifier : git --version

macOS

Deux options :

# Option 1 : via les outils en ligne de commande Apple
xcode-select --install

# Option 2 : via Homebrew (si tu l'as installé)
brew install git

Pour vérifier : git --version

Première configuration

Git a besoin de savoir qui tu es. Chaque modification que tu enregistreras portera ta signature - un nom et une adresse email. C'est obligatoire.

Ouvre un terminal (Git Bash sur Windows) et tape ces deux commandes en remplaçant les valeurs entre guillemets par les tiennes :

git config --global user.name "Ton Nom"
git config --global user.email "ton@email.com"

Tu n'es pas obligé d'utiliser ton vrai nom. Un pseudonyme fonctionne parfaitement. Beaucoup de contributeurs open source utilisent un pseudo et une adresse email dédiée. L'important, c'est que Git puisse identifier l'auteur de chaque modification.

L'option --global signifie que cette configuration s'applique à tous tes projets Git sur cette machine. Tu n'auras à le faire qu'une seule fois.

Pour vérifier que tout est bien enregistré :

git config --global user.name
git config --global user.email

Ces commandes doivent afficher respectivement ton nom et ton email.

Configurer la branche par défaut

Depuis 2020, la convention moderne est d'appeler la branche principale main au lieu de l'historique master. Configure cette préférence globalement pour que tous tes futurs git init créent automatiquement une branche main :

git config --global init.defaultBranch main

Cette configuration est importante pour les quêtes suivantes. Sans elle, certaines instructions qui supposent une branche main échoueront sur ton premier git init.

Configuration par projet

Tu peux vouloir utiliser un pseudo sur tes projets personnels en ligne, mais ton vrai nom (ou un trigramme) sur tes projets professionnels. Git le permet grâce à l'option --local, qui remplace la configuration globale uniquement pour le dépôt en cours :

# Dans un dépôt professionnel
cd mon-projet-pro/
git config --local user.name "Jean Dupont"
git config --local user.email "jdupont@entreprise.com"

La priorité est simple : --local (par projet) l'emporte toujours sur --global (par machine). Ainsi tu peux garder ton pseudo en global et ne configurer --local que dans les dépôts qui nécessitent une identité différente.

--global = configuration par défaut pour toute la machine. --local = configuration spécifique à un seul dépôt. Le local a toujours la priorité.

Un mot sur la sécurité

Tu l'auras peut-être remarqué : rien ne t'empêche de configurer user.name avec le nom de quelqu'un d'autre. Tu pourrais très bien écrire git config user.name "Linus Torvalds" et tous tes commits porteraient son nom. Git ne vérifie pas ton identité - il se contente d'enregistrer ce que tu lui donnes.

C'est une limitation connue et assumée. Pour les projets où l'authenticité compte vraiment, il existe une solution : la signature cryptographique des commits. En utilisant une clé GPG (ou SSH), tu peux prouver mathématiquement que c'est bien toi qui as créé un commit. Les plateformes comme GitHub affichent alors un badge "Verified" à côté du commit.

La signature des commits est un sujet avancé que nous n'aborderons pas dans cette quête. Retiens simplement que user.name et user.email sont déclaratifs - c'est la clé cryptographique qui fait office de vraie preuve d'identité.

Exercice pratique - Validation de la quête

Lance le script de vérification pour valider que Git est installé et configuré correctement sur ta machine.

Bash (Linux / macOS / Git Bash sur Windows) :

bash verifier.sh

PowerShell (Windows) :

.\verifier.ps1

Le script vérifie quatre choses :

  1. Git est installé sur ta machine
  2. Ton nom est configuré (user.name)
  3. Ton email est configuré (user.email)
  4. Ta branche par défaut est main (init.defaultBranch)

Si les quatre étapes sont validées, félicitations ! Tu es officiellement membre de la Guilde des Archivistes. La prochaine quête t'attend.

Le Maître Archiviste hoche la tête avec satisfaction.

« Bien. Tu as fait tes premiers pas. Tu possèdes maintenant l'outil fondamental de tout Archiviste. Dans la prochaine quête, je t'emmènerai dans les Trois Salles du Savoir - tu y découvriras comment Git organise le travail. Prépare-toi. »