← Retour à l'accueil

Cours 01

Introduction au versioning avec Git et GitHub

Cette première séance installe le socle Git et GitHub nécessaire aux workflows collaboratifs des cours suivants.

Consignes de séance

Chaque notion est associée à une manipulation courte afin de relier immédiatement les commandes Git à l'état réel du dépôt.

À vérifier avant les manipulations

  • Un compte GitHub actif doit être accessible.
  • Un terminal doit pouvoir être ouvert sur la machine.
  • Git doit être installé et un éditeur doit permettre de modifier des fichiers texte.
  • VS Code ou GitHub Desktop peuvent compléter la ligne de commande pour observer les changements.

La page Cours 00 · Prérequis techniques détaille les vérifications à faire en autonomie.

Pourquoi versionner

Le versioning sert à enregistrer, suivre et organiser l'évolution d'un projet. Il permet de revenir en arrière, de comprendre qui a fait quoi et de travailler à plusieurs sans perdre la mémoire du projet.

Les changements, les décisions et les états fiables du projet sont conservés dans un historique consultable.

Les copies de dossiers confuses qui finissent en v-finale-bis-cette-fois sont remplacées par des versions identifiées.

Historiquement, RCS, CVS puis Subversion ont préparé le terrain. Git a ensuite imposé une logique distribuée, rapide et adaptée au travail collaboratif moderne.

Quels types de problèmes de collaboration peuvent être réduits par un historique versionné ?
  • La perte de contexte sur l'auteur, la date et l'intention d'une modification.
  • L'écrasement involontaire d'un travail récent faute d'état de référence partagé.
  • La difficulté à revenir vers un état stable après une erreur ou une régression.
  • La comparaison laborieuse entre plusieurs versions concurrentes d'un même fichier.

Une vue d'historique aide souvent à comprendre le principe en quelques secondes.

Chargement du gitGraph…

Le modèle mental Git

Git n'est pas juste une liste de commandes. Il manipule une zone de travail, un index et un historique de commits. Tant que ce schéma n'est pas clair, les commandes ressemblent à des recettes. Quand il devient clair, elles deviennent logiques.

Chargement du flowchart…

Zone de travail : l'état courant des fichiers sur le disque.

Index : la sélection de changements préparée pour le prochain commit.

Commit : un point de sauvegarde créé à partir du contenu présent dans l'index.

Historique de commits : la suite structurée des instantanés successifs du projet.

Git en local : les commandes de base

Le cycle minimal doit être maîtrisé avant les branches, les PR et les conflits : créer un dépôt, observer l'état, sélectionner ce qui doit être validé et créer un commit propre.

Initialiser un dépôt 

git init

Transforme un dossier ordinaire en dépôt Git en créant le répertoire caché .git/.

Observer l'état 

git status

Montre les fichiers suivis, non suivis, modifiés et prêts pour le prochain commit.

Préparer puis valider 

git add mon-fichier.txt
git commit -m "Premier commit"

Le bon contenu est placé dans l'index, puis un point de sauvegarde est créé dans l'historique.

Lire l'historique 

git log --oneline --decorate

Cette commande donne une vue compacte des commits et des références qui pointent vers eux.

À savoir

Utiliser git add selon le besoin 

git add fichier.txt
git add dossier/
git add .
git add *.md
git add -p

Le choix dépend de la précision attendue : un fichier isolé, un dossier, tout le répertoire courant, un motif de fichiers ou une sélection interactive par bloc.

Comprendre git commit 

git commit -m "Ajoute le fichier de notes"
git commit

Un commit n'enregistre que le contenu déjà placé dans l'index. Sans git add préalable, rien n'est réellement prêt à être validé.

Garder le dépôt propre avec .gitignore 

*.log
/temp/
secret.txt
node_modules/

Le fichier .gitignore évite de versionner des secrets, dépendances ou fichiers temporaires.

TP 1 : exercice guidé en local (15 min)

Le but est d'enchaîner une première boucle complète sans difficulté artificielle. Le résultat attendu est un dépôt propre et un historique compréhensible.

  1. Créer un nouveau dossier de travail et l'initialiser avec git init.
  2. Créer un fichier texte avec quelques lignes puis observer git status.
  3. Préparer le fichier avec git add, vérifier à nouveau l'état.
  4. Créer un premier commit, puis afficher l'historique avec git log --oneline.
  5. Ajouter un .gitignore simple et expliquer à quoi il sert dans un vrai projet.
Que se passe-t-il si la commande git commit est lancée avant git add ?

Le commit ne prend en compte que l'état déjà présent dans l'index. Si aucun fichier n'a été ajouté auparavant, Git signale généralement qu'il n'y a rien à valider.

Cette séparation entre préparation et validation évite qu'un changement encore non relu soit enregistré par erreur dans l'historique.

GitHub et les dépôts distants

Une fois la boucle locale maîtrisée, un dépôt distant est ajouté. C'est là qu'entrent en jeu GitHub, les clés SSH, les remotes et la synchronisation entre le travail local et le serveur.

Mise en route GitHub 

git config --global user.name "Votre Nom"
git config --global user.email "vous@example.com"

ssh-keygen -t ed25519 -C "vous@example.com"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

git config --global user.name définit le nom qui apparaît dans les commits.

git config --global user.email définit l'adresse associée aux commits. L'adresse peut être celle du compte GitHub ou une adresse GitHub masquée.

ssh-keygen crée une paire de clés SSH. La clé publique doit ensuite être ajoutée dans GitHub.

eval "$(ssh-agent -s)" démarre l'agent SSH, puis ssh-add charge la clé privée pour les connexions GitHub.

En cas de blocage, la fiche Aide GitHub récapitule les diagnostics rapides.

Commandes à connaître

Ici, il faut distinguer deux situations très différentes : soit un dépôt local existe déjà et doit être connecté à GitHub, soit le dépôt existe déjà sur GitHub et doit être récupéré sur la machine.

Cas 1 : un dépôt local existe déjà 

git remote add origin git@github.com:compte/repo.git

Cette commande ajoute un dépôt distant au dépôt local. Le nom origin n'a rien de magique : c'est juste le nom conventionnel donné au dépôt distant principal. À ce stade, rien n'est encore envoyé sur GitHub : Git reçoit seulement l'adresse du serveur distant. 

git remote -v

Cette commande sert à vérifier les URLs configurées pour le fetch et le push. C'est un bon réflexe de contrôle : avant un push, l'URL affichée doit pointer vers le bon dépôt. 

git push -u origin main

La branche locale main est envoyée sur le dépôt distant nommé origin. L'option -u crée le lien de suivi entre la branche locale et la branche distante. Après ce premier push, un simple git push ou git pull suffit souvent.

Cas 2 : le dépôt existe déjà sur GitHub 

git clone git@github.com:compte/repo.git

Cette commande crée un nouveau dossier local contenant une copie du dépôt distant, avec l'historique, les branches et la remote origin déjà configurée. C'est la bonne commande lorsqu'un projet déjà hébergé sur GitHub doit être récupéré prêt à l'emploi.

Clarifier fetch et pull

git fetch met à jour la connaissance du distant, alors que git pull récupère puis intègre ces changements dans la branche courante.

Avec git fetch, les changements distants sont consultés sans modifier immédiatement les fichiers locaux.

Avec git pull, les nouveautés sont récupérées puis intégrées directement dans la branche courante.

En pratique, fetch est plus prudent pour observer avant d'intégrer ; pull est plus direct lorsque la branche courante doit être mise à jour immédiatement.

Un gitGraph simple permet de visualiser l'écart entre travail local, branche de feature et intégration.

Chargement du gitGraph…

Côté interface graphique, VS Code est suffisant pour montrer les changements locaux, la branche courante, les commits et la synchronisation. GitHub Desktop peut être également utilisé.

Préflight GitHub avant le TP collectif

Avant une manipulation collective, la configuration GitHub doit être vérifiée pour éviter de confondre problème de commande et problème d'accès.

Contrôles rapides 

git --version
git config --global user.name
git config --global user.email
ssh -T git@github.com

Les trois premières commandes vérifient l'installation Git et l'identité de commit. La dernière teste l'authentification SSH auprès de GitHub.

Choix HTTPS ou SSH

SSH est recommandé si une clé est installée et acceptée par GitHub. HTTPS reste utilisable avec un jeton d'accès personnel, notamment si la configuration SSH n'est pas terminée au moment du TP.

En cas d'erreur d'accès, de mauvais remote ou d'éditeur bloqué pendant un commit de merge, utiliser la fiche Aide GitHub.

TP 2 : expérience collective anarchique (20 min)

Tout le monde intervient sur le même README public, dans un ordre imposé pendant le cours. Le dépôt est volontairement peu protégé pour rendre visibles les limites d'une collaboration sans méthode.

Dépôt support : GVI2026/git-anarchique

  1. Cloner le dépôt support fourni pour la séance.
  2. Ajouter une unique courte ligne signée sous le commentaire existant dans le README.
  3. Respecter l'ordre de passage imposé pendant le cours.
  4. Observer ce qui se passe quand plusieurs personnes travaillent sans garde-fous suffisants.
À retenir après une collaboration sans méthode

Sans méthode, les collisions, les retards, les incompréhensions et les risques d'écrasement apparaissent rapidement.

Le dépôt public agit ici comme un laboratoire : il rend visibles les raisons d'introduire branches, PR, reviews et règles de protection.

Branches, checkout, switch et pull requests

Créer une branche : git branch nom-de-branche.

Basculer proprement : git switch nom-de-branche ou, historiquement, git checkout nom-de-branche.

Créer et basculer en une fois : git switch -c ma-feature ou git checkout -b ma-feature.

Explorer un commit passé : git checkout <identifiant-de-commit> pour lire un état en detached HEAD.

Une Pull Request est une proposition de modification publiée sur GitHub : une branche est comparée à une branche cible, puis la discussion, les tests et la relecture déterminent si le changement peut être intégré.

Elle devient utile dès que plusieurs personnes travaillent ensemble : elle isole une proposition de changement, permet une relecture et s'associe naturellement aux protections GitHub.

Chargement du gitGraph…

Résoudre des conflits Git individuellement (30 min)

Le dépôt git-moins-anarchique est réutilisé ici pour travailler les conflits dans un cadre déjà plus structuré que celui du TP collectif précédent. Les conflits ne doivent pas rester une abstraction : ils sont travaillés en local, sur des branches déjà préparées, avec un exercice de merge puis un exercice de rebase.

Chargement du gitGraph…

Exercice 1 : conflit avec merge

Dépôt support : git-moins-anarchique 

git clone https://github.com/GVI2026/git-moins-anarchique.git
cd git-moins-anarchique
git checkout ex/merge-depart
git checkout -b mon-merge
git merge ex/merge-a-integrer

Résoudre ensuite le conflit dans docs/planning-sprint.txt, puis valider avec git add et git commit.

Vérification et annulation

Contrôle : git status puis git log --graph --oneline --decorate -5.

Résultat attendu : plus de marqueurs <<<<<<<, un fichier cohérent et un commit de merge.

Annulation si besoin : git merge --abort.

Exercice 2 : conflit avec rebase 

git checkout ex/rebase-feature
git checkout -b mon-rebase
git rebase ex/rebase-base

Résoudre le conflit dans docs/notes-version.txt, ajouter le fichier puis continuer avec git rebase --continue.

Vérification et annulation

Contrôle : git status puis git log --graph --oneline --decorate -5.

Résultat attendu : plus de conflit, aucun marqueur restant et un historique linéaire sans commit de merge.

Annulation si besoin : git rebase --abort.

Conseils généraux de résolution

Lire les deux versions avant de supprimer les marqueurs <<<<<<<, ======= et >>>>>>>.

Vérifier le sens métier du texte final, pas seulement la disparition du conflit.

Utiliser git diff après résolution pour contrôler le résultat réel.

Si l'éditeur reste ouvert pendant le commit de merge, consulter la fiche Aide GitHub.

TP 3 : rejouer l'expérience avec une méthode (15 min)

Après les exercices de merge et de rebase, le même dépôt peut être relu comme un exemple de collaboration plus cadrée que celle de TP 2. Les branches personnelles, les pull requests et les règles GitHub y transforment une contribution isolée en proposition vérifiable.

Dépôt support : GVI2026/git-moins-anarchique

  • Une branche de travail personnelle est créée pour chaque contribution.
  • Une pull request sert d'étape d'intégration avant l'arrivée sur la branche cible.
  • Des protections de branche et des rôles explicites cadrent la validation.
  • Le flux devient reproductible, traçable et plus simple à relire collectivement.
Quels garde-fous ont été mis en place pour rendre une collaboration plus fiable ?

La branche ruleset matérialise les contraintes imposées dans le dépôt : le travail direct sur la branche principale n'est plus la voie normale, une branche dédiée doit être créée, puis une pull request doit porter l'intégration.

Ces règles renforcent la traçabilité, rendent la relecture possible avant fusion et évitent qu'une bonne pratique repose uniquement sur la discipline individuelle.

Release, Semantic Versioning et Conventional Commits

Un recul est ensuite pris sur la manière dont une version est nommée, sur ce qu'une release représente et sur l'intérêt d'une convention de message pour le travail d'équipe.

Release : une version identifiable, partageable et souvent livrable du projet.

SemVer : Major.Minor.Patch, donc compatibilité cassée, nouvelle fonctionnalité compatible, puis correctif.

Conventional Commits : une convention simple pour donner du sens aux commits et préparer plus facilement changelog et automatisations futures.

Défi Semantic Versioning

À partir de v3.6.12, quelle version annoncer après un correctif, une fonctionnalité ou une rupture de compatibilité ?

Réponses attendues

Correctif seul : v3.6.13.

Nouvelle fonctionnalité compatible : v3.7.0.

Correctif + fonctionnalité : v3.7.0.

Correctif majeur de sécurité et changement cassant : v4.0.0.

Exemples de messages de commit respectant Conventional Commits 

feat: ajoute une fonctionnalité X
fix: corrige un conflit d'accès à une ressource
docs: clarifie les consignes du TP 2
chore: optimise la récupération des données

Pour aller plus loin

gitbybit.com pour revisiter Git avec d'autres explications et visuels.

Le vocabulaire Git de Stéphane Robert pour revenir sur les notions Tree, Blob, DAG et Ref.

Git cheat sheet GitHub Education pour garder les commandes à portée de main.

La suite logique n'est pas encore le DevOps complet. Le prochain pas consiste à structurer des flows de développement : quand brancher, quand relire, quand intégrer et comment garder une base stable en équipe.