← Retour à l'accueil

Cours 01

Introduction au versioning avec Git et GitHub

Cette séance pose le socle du module. On commence par comprendre pourquoi on versionne, on pratique Git en local, puis on vit une vraie collaboration sur GitHub avant de traiter les conflits, les releases et les conventions de commits.

Démarrage

L'idée n'est pas de faire un cours magistral long, mais de construire un rythme simple : une notion, une question, une manipulation, puis un débrief. Le site est visible dès le début, donc les réponses de correction sont présentes mais cachées quand c'est utile.

Prérequis

  • Avoir un compte GitHub actif avant le cours.
  • Pouvoir ouvrir un terminal sur sa machine.
  • Avoir Git installé et un éditeur prêt à modifier des fichiers texte.
  • VS Code ou GitHub Desktop peuvent servir à comparer ligne de commande et interface graphique.

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.

On s'en sert pour mémoriser les changements, garder une trace des décisions et retrouver un état fiable si une régression apparaît.

On s'en sert aussi pour éviter les copies de dossiers confuses qui finissent en v-finale-bis-cette-fois.

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.

Qu'est-ce que vous gagnez vraiment par rapport à un dossier copié à la main ?

On gagne un historique lisible, des points de retour clairs, des auteurs identifiés et un cadre robuste pour collaborer.

Autrement dit, on remplace des copies de dossiers confuses par une évolution traçable du projet.

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, une zone de transit 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…

Working tree : l'état courant des fichiers sur le disque.

Index / staging area : l'endroit où l'on prépare le prochain commit.

Commit graph : le graphe des instantanés successifs.

Tree / Blob / DAG / Ref : que faut-il retenir aujourd'hui ?

Blob : le contenu d'un fichier versionné.

Tree : une vue d'arborescence qui relie dossiers et blobs.

DAG : la forme de l'historique des commits.

Ref : un nom qui pointe vers un commit, comme une branche ou un tag.

Git en local : les commandes de base

On commence sans branches, sans PR et sans conflit. Il faut d'abord maîtriser le cycle minimal : créer un dépôt, observer l'état, sélectionner ce qu'on valide 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 add .
git commit -m "Premier commit"

On place le bon contenu dans l'index, puis on crée un point de sauvegarde 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.

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

Le but est d'enchaîner une première boucle complète sans difficulté artificielle. Vous devez sortir de ce bloc avec 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.
Vérifiez votre résultat

Après git init, le dossier contient désormais un répertoire .git/.

Après création du fichier, git status doit signaler un fichier non suivi.

Après git add, ce même fichier doit apparaître comme prêt à être validé.

Après le commit, l'arbre de travail doit redevenir propre et l'historique doit montrer un commit.

GitHub et les dépôts distants

Une fois la boucle locale maîtrisée, on ajoute un dépôt distant. 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

Copier ensuite la clé publique dans GitHub puis relier un dépôt local à une remote avec git remote add origin.

Commandes à connaître

Ici, il faut distinguer deux situations très différentes : soit vous avez déjà un dépôt local et vous voulez le connecter à GitHub, soit le dépôt existe déjà sur GitHub et vous voulez le récupérer sur votre machine.

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

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

Cette commande ajoute un dépôt distant à votre dépôt local. Le nom origin n'a rien de magique : c'est juste le nom conventionnel qu'on donne au dépôt distant principal. À ce stade, rien n'est encore envoyé sur GitHub : vous dites seulement à Git où se trouve le 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 d'envoyer quoi que ce soit, vous vérifiez que vous pointez bien vers le bon dépôt. 

git push -u origin main

Ici, vous envoyez votre branche locale main 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. Concrètement, après ce premier push, vous pourrez souvent vous contenter d'un simple git push ou git pull.

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 quand vous partez d'un projet déjà hébergé sur GitHub et que vous voulez le récupérer 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, vous regardez d'abord ce qui a changé sans modifier immédiatement vos fichiers locaux.

Avec git pull, vous demandez à Git de récupérer les nouveautés puis de les intégrer directement dans votre branche courante.

En pratique, fetch est plus prudent quand vous voulez observer avant d'intégrer ; pull est plus direct quand vous savez que vous voulez vous mettre à jour.

Si vous hésitez entre `fetch` et `pull`, que devez-vous retenir ?

git fetch = je regarde ce qui a changé à distance sans modifier directement mon travail local.

git pull = je fais un fetch puis j'intègre le résultat, le plus souvent via un merge ou un rebase selon la configuration.

Formule courte utile : pull = fetch + intégration.

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é.

TP 2 : expérience collective anarchique

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 ou forker le dépôt selon l'organisation choisie en 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.
À débriefer juste après

Sans méthode, on voit vite apparaître des collisions, des retards, des incompréhensions et des risques d'écrasement.

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.

La pull request 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…

Dans VS Code, on peut rendre visible une partie de ce flux : changements locaux, branche courante, commit, synchronisation puis ouverture d'une PR via GitHub.

TP 3 : rejouer l'expérience avec une méthode

Le dépôt suivant reprend le même esprit que TP-2 mais dans un cadre plus structuré. C'est le bon moment pour parler de branches personnelles, de PR, de revue et de règles GitHub.

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

  • Une branche de travail personnelle.
  • Une PR pour proposer le changement.
  • Des règles de protection et des rôles plus explicites.
  • Un flux de travail reproductible plutôt qu'un simple réflexe opportuniste.
Qu'est-ce qui change pour vous par rapport au TP-2 ?

La méthode fait baisser le chaos visible, améliore la traçabilité et rend les conflits plus gérables.

Le coût est un peu plus de formalisme, mais ce formalisme devient rentable dès qu'on travaille à plusieurs.

Résoudre des conflits Git individuellement

Les conflits ne doivent pas rester une abstraction. On les travaille ici 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.

Si vous bloquez, affichez ces conseils 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.

Release, Semantic Versioning et Conventional Commits

On termine en prenant un peu de hauteur : comment nommer correctement une version, ce qu'est une release et pourquoi une convention de message peut aider toute l'é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 si l'on ajoute un correctif, une fonctionnalité ou une rupture de compatibilité ?

Vérifiez vos réponses

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 utiles 

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.