Foundations of Version Control

Niveau : Beginner

Durée : 2h

Prérequis

Connaissances de base en informatique
Savoir créer et modifier des fichiers

Objectifs d'apprentissage

Comprendre les problèmes du développement sans gestion de versions
Découvrir l'histoire des systèmes de contrôle de version
Comprendre la différence entre Git et GitHub
Comprendre l'architecture interne de Git
Réaliser ses premiers commits et naviguer dans le terminal interactif

Introduction

Imaginez que vous développez une application pendant plusieurs semaines.

Le projet évolue progressivement :

app/
├── index.js
├── style.css
└── README.md

Après plusieurs modifications, vous obtenez ceci :

app-final/
app-final-v2/
app-final-v3/
app-final-corrige/
app-final-vraiment-final/

Quelques jours plus tard, un bug apparaît.

Une question simple devient alors extrêmement difficile :

Quelle version fonctionnait correctement ?

Ou encore :

Qui a introduit cette modification ?

Le contrôle de version est né pour résoudre précisément ce problème.

Pourquoi le contrôle de version est-il indispensable ?

Le développement logiciel est une activité évolutive.

Une application :

change constamment ;
corrige des erreurs ;
ajoute des fonctionnalités ;
est maintenue par plusieurs personnes.

Sans système de version :

des fichiers sont perdus ;
des modifications sont écrasées ;
les erreurs deviennent difficiles à identifier ;
la collaboration devient presque impossible.

Problème 1 : Perte de travail

Deux développeurs modifient le même fichier :

Développeur A
        ↓
     app.js
        ↑
Développeur B

Le second enregistrement peut écraser le travail du premier.

Conséquences :

perte de temps ;
conflits ;
régressions ;
frustration.

Problème 2 : Impossible de revenir en arrière

Une nouvelle fonctionnalité introduit un bug critique.

Sans historique :

impossible de savoir ce qui a changé ;
impossible de restaurer rapidement une version stable.

Problème 3 : Manque de traçabilité

Questions auxquelles il devient difficile de répondre :

Qui a modifié ce fichier ?
Quand ?
Pourquoi ?
Quel était l’objectif de cette modification ?

La solution : le contrôle de version

Un système de contrôle de version permet de :

enregistrer l’historique du projet
conserver plusieurs versions
revenir en arrière
travailler en équipe
expérimenter sans risque

Définition

Un système de contrôle de version (Version Control System ou VCS) est un outil permettant de suivre et gérer l’évolution d’un projet informatique dans le temps.

Il agit comme une machine à voyager dans le temps pour votre code.

Évolution des systèmes de version

Gestion manuelle

Projet
Projet-v2
Projet-v3
Projet-final
Projet-final-corrige
Projet-final-vraiment-final

Cette approche fonctionne rarement au-delà d’une seule personne.

CVS

Le Concurrent Versions System fut l’une des premières solutions de gestion collaborative.

Avantages :

historique des modifications ;
gestion des versions.

Limites :

architecture ancienne ;
performances limitées.

SVN (Subversion)

Architecture :

graph TD
A[Développeur 1] --> B[Serveur Central]
C[Développeur 2] --> B
D[Développeur 3] --> B

Avantages :

centralisation ;
historique partagé ;
gestion des accès.

Inconvénients :

dépendance au serveur central ;
travail hors ligne limité ;
gestion des branches coûteuse.

Mercurial

Mercurial introduit une approche distribuée.

Chaque développeur possède une copie complète du projet.

Cette approche améliore :

les performances ;
la résilience ;
la collaboration.

Git

En 2005, le développement du noyau Linux nécessitait :

de la rapidité ;
une grande fiabilité ;
des milliers de contributions simultanées ;
une gestion efficace des branches.

Git a été créé pour répondre à ces besoins.

Aujourd’hui, Git est devenu le standard mondial du développement logiciel moderne.

Git n’est pas GitHub

Cette confusion est extrêmement fréquente.

Git

Git est un logiciel installé sur votre ordinateur.

Il fonctionne :

localement ;
sans Internet ;
sans serveur distant.

Exemple :

git init
git add .
git commit -m "Premier commit"

GitHub

GitHub est une plateforme d’hébergement de dépôts Git.

GitHub ajoute :

la collaboration en ligne ;
les Pull Requests ;
les Issues ;
les revues de code ;
l’intégration continue ;
la documentation.

Analogie

Git        = le moteur
GitHub     = le garage collaboratif
Repository = le véhicule

Architecture de Git

Git fonctionne comme une chaîne de transformation.

flowchart LR
A[Working Directory]
--> B[Staging Area]
--> C[Local Repository]
--> D[Remote Repository]

Working Directory

Le Working Directory est votre espace de travail.

Vous créez :

des fichiers ;
des dossiers ;
des modifications.

Exemple :

mon-projet/
├── README.md
├── app.js
└── style.css

À ce stade, Git n’a encore rien sauvegardé.

Staging Area

La Staging Area est une zone de préparation.

Vous indiquez à Git :

Voici exactement ce que je souhaite enregistrer.

Commande :

git add .

Repository Local

Lorsque vous effectuez :

git commit

Git crée un instantané du projet.

Un commit représente :

l’état complet du projet ;
une description ;
un identifiant unique.

Remote Repository

Le dépôt distant permet :

la sauvegarde ;
le partage ;
la collaboration.

Exemple :

GitHub
GitLab
Bitbucket

Cycle de vie d’une modification

flowchart TD
A[Modifier un fichier]
--> B[git status]
--> C[git add]
--> D[git commit]
--> E[git push]

Premier exercice : Terminal virtuel

Pratiquez l’enchaînement de vos premières commandes Git à l’aide de notre terminal interactif ci-dessous :

Commandes à exécuter

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$ _

Mini Challenge

Suivez ces instructions pour réaliser votre premier atelier sur votre propre terminal local :

Votre Progression 0%

Initialiser un nouveau dépôt Git local dans un dossier vide.
Créer les fichiers README.md, index.html, style.css et app.js.
Ajouter et commiter le README.md en premier avec le message 'Initial commit'.
Ajouter et commiter le fichier index.html avec le message 'Ajoute la structure HTML'.
Ajouter et commiter le fichier style.css avec le message 'Ajoute les styles CSS'.
Ajouter et commiter le fichier app.js avec le message 'Ajoute le script JavaScript'.
Mettre à jour le README.md et faire le cinquième commit avec le message 'Met à jour la documentation'.

Fiches de révision (Flashcards)

Entraînez-vous à retenir les concepts clés en cliquant sur les cartes ci-dessous :

Question

Quelle commande initialise un nouveau dépôt Git local ?

Cliquer pour révéler la réponse

Réponse

git init

Cliquer pour voir la question

Question

Quelle commande permet de vérifier le statut de la Staging Area ?

Cliquer pour révéler la réponse

Réponse

git status

Cliquer pour voir la question

Question

Quelle commande prépare tous les fichiers modifiés pour le prochain commit ?

Cliquer pour révéler la réponse

Réponse

git add .

Cliquer pour voir la question

Question

Quelle commande enregistre définitivement vos modifications dans l'historique ?

Cliquer pour révéler la réponse

Réponse

git commit -m "message"

Cliquer pour voir la question

Quiz d’évaluation

Quelle est la principale différence entre Git et GitHub ?

Erreurs fréquentes

Faire un seul commit après plusieurs heures de travail.
Oublier de décrire ses commits.
Modifier directement les fichiers sans vérifier leur état.
Considérer GitHub comme Git lui-même.

Cheat Sheet

git init
git status
git add .
git commit -m "message"
git log

À retenir

Le développement moderne nécessite un historique fiable.
Le contrôle de version permet de suivre l’évolution du code.
Git est un système de contrôle de version distribué.
GitHub est une plateforme de collaboration basée sur Git.
Git fonctionne selon quatre espaces :

Working Directory -> Staging Area -> Repository -> Remote Repository

Vous venez d’apprendre les fondations sur lesquelles repose l’ingénierie collaborative moderne.