Git et versioning : comprendre le contrôle de version
Ce cours t'apprend ce qu'est le versioning et comment Git l'organise concrètement. Tu comprendras pourquoi les développeurs ne travaillent presque jamais sans lui, même seul sur un projet.
1.Qu'est-ce que le versioning et pourquoi
Imagine que tu écris un rapport de 50 pages. Tu fais une modification, puis une autre, et au bout d'une semaine tu réalises qu'une version d'avant était meilleure. Sans outil, tu dois garder des copies nommées rapport_v1, rapport_final, rapport_final2. Le versioning résout ce problème : c'est une méthode pour enregistrer l'historique complet des changements d'un fichier ou d'un projet, avec la possibilité de revenir en arrière à tout moment. Git est le logiciel de versioning le plus utilisé au monde, créé en 2005 par Linus Torvalds, le créateur de Linux. Contrairement à un simple dossier de copies, Git enregistre uniquement les différences entre chaque état du projet, ce qui rend l'historique léger et consultable en quelques secondes, même sur un projet avec 10 000 fichiers.
- Le versioning garde une trace de chaque modification dans le temps.
- Git enregistre des différences, pas des copies complètes à chaque fois.
- Créé en 2005, Git est un logiciel gratuit et open source.
2.Le dépôt et les trois zones de travail
Un dépôt, ou repository, est le dossier où Git stocke tout l'historique d'un projet. Il contient un sous-dossier caché nommé .git, invisible dans l'explorateur de fichiers classique, qui garde toute la mémoire du projet. À l'intérieur, Git organise le travail en trois zones. Le répertoire de travail, c'est ton dossier normal où tu modifies les fichiers. La zone de préparation, appelée staging area ou index, sert de salle d'attente : tu y places les fichiers que tu veux enregistrer. Le dépôt local enfin contient l'historique validé. Par exemple, si tu modifies deux fichiers sur cinq, tu peux choisir de ne préparer qu'un seul fichier pour l'enregistrer, l'autre restant en attente. Cette séparation en trois zones donne un contrôle précis sur ce qui est réellement sauvegardé.
- Le dossier .git contient tout l'historique, il ne faut jamais le supprimer.
- La zone de préparation permet de choisir précisément quoi enregistrer.
- Le dépôt local stocke les versions validées du projet.
3.Le commit, unité de base de l'historique
Un commit est une photographie du projet à un instant donné. Chaque commit a un identifiant unique, une longue chaîne de caractères comme a3f5c9d, un auteur, une date et un message décrivant ce qui a changé. Par exemple, tu corriges une faute dans un fichier, tu la places en zone de préparation, puis tu la valides avec un message comme corrige la faute de frappe dans le titre. Ce commit devient un point fixe de l'historique, consultable à jamais. L'ensemble des commits forme une chaîne, chacun pointant vers le précédent, un peu comme les maillons d'une chaîne. Cela permet de revenir à n'importe quel état passé du projet, de comparer deux versions, ou de comprendre qui a modifié quoi et pourquoi, ce qui est essentiel quand plusieurs personnes travaillent ensemble.
- Un commit capture l'état complet du projet à un moment précis.
- Chaque commit a un identifiant unique et un message explicatif.
- Les commits forment une chaîne chronologique reliée entre eux.
4.Les branches pour travailler en parallèle
Une branche est une ligne de développement indépendante à partir d'un point donné de l'historique. La branche principale s'appelle souvent main ou master. Imagine une équipe de trois développeurs sur une application : l'un corrige un bug urgent, l'autre ajoute une fonctionnalité de paiement, le troisième teste une nouvelle interface. Sans branches, ils écraseraient leur travail mutuellement. Chacun crée sa propre branche, travaille dessus sans affecter les autres, puis fusionne son travail dans la branche principale une fois terminé. Cette fusion s'appelle un merge. Parfois, deux branches modifient la même ligne du même fichier de façon différente : Git ne peut pas décider seul, cela s'appelle un conflit, et il faut choisir manuellement quelle version garder. Les branches rendent le travail collaboratif possible sans chaos.
- Une branche isole un développement sans perturber le reste du projet.
- Le merge réunit le travail d'une branche dans une autre.
- Un conflit survient quand deux modifications contradictoires se rencontrent.
5.Travailler à plusieurs avec un dépôt distant
Jusqu'ici, tout se passait sur ton ordinateur, dans le dépôt local. Mais le versioning devient vraiment utile en équipe grâce au dépôt distant, une copie du projet hébergée sur un serveur, souvent sur des plateformes comme GitHub, GitLab ou Bitbucket. La commande push envoie tes commits locaux vers ce dépôt distant, pour les partager avec l'équipe. La commande pull récupère les commits que les autres ont ajoutés depuis. Par exemple, une équipe de dix personnes travaille chacune sur sa branche, pousse ses changements chaque soir, et récupère le travail des autres le matin avant de continuer. GitHub ajoute aussi des outils autour de Git, comme les pull requests, qui permettent de proposer une fusion et de la faire relire par un collègue avant de l'accepter, un filtre de qualité essentiel en entreprise.
- Le dépôt distant est une copie partagée hébergée sur un serveur.
- Push envoie tes commits, pull récupère ceux des autres.
- La pull request permet une relecture avant fusion du code.
6.Erreurs fréquentes et points d'examen
L'erreur la plus commune est d'oublier de faire un pull avant de commencer à travailler, ce qui crée des conflits inutiles. Une autre est de committer directement sur la branche principale au lieu de créer une branche dédiée, ce qui complique le travail en équipe. Beaucoup confondent aussi le répertoire de travail et la zone de préparation, en pensant qu'un fichier modifié est automatiquement sauvegardé par Git, alors qu'il faut explicitement le préparer puis le committer. À l'examen, on te demandera souvent de distinguer les trois zones, d'expliquer la différence entre commit et push, ou de décrire ce qu'est un conflit et comment le résoudre. On teste aussi la compréhension du rôle du fichier .gitignore, qui liste les fichiers à ne jamais suivre, comme les mots de passe ou les fichiers temporaires générés automatiquement.
- Toujours faire un pull avant de commencer une session de travail.
- Ne jamais committer directement sur la branche principale en équipe.
- Le fichier .gitignore exclut certains fichiers du suivi de Git.
À retenir
- 1Le versioning enregistre l'historique complet d'un projet pour permettre de revenir en arrière.
- 2Git organise le travail en trois zones : répertoire de travail, staging area et dépôt local.
- 3Un commit est une photographie datée et identifiée du projet à un instant précis.
- 4Les branches permettent à plusieurs personnes de travailler sans se marcher dessus.
- 5Push et pull synchronisent le dépôt local avec un dépôt distant partagé en équipe.
Dix questions sur ce sujet démarrent tout de suite, corrigées et expliquées.
L'essentiel en six phrases, à relire la veille.
Cours rédigé par intelligence artificielle et relu au fil des retours. Pour un examen officiel, garde tes cours et les textes en vigueur comme référence.