Git et GitHub
Git fonctionne aussi localement, sans compte GitHub. GitHub illustre le dépôt distant ; d’autres plateformes Git ou un dossier local versionné peuvent être utilisés selon les objectifs de l’exercice.
Chapitres, TP et corrigés consultables ; les TP sont principalement à réaliser hors de la page. Trois questions d’entraînement interactif facultatif sont proposées dans ce module, sans note ni validation automatique. Le manuel de formation est également consultable depuis le lien en haut de page. Les durées sont des repères pour organiser le parcours ; les lectures, activités, travaux pratiques et évaluations ne doivent pas être additionnés deux fois.
Dans ce module — Accès rapide
MODULE 6 — GIT ET GITHUB
Bloc B — Développer et publier | Durée : 10 heures | Niveau : débutants complets
Objectifs et critères de réussite
Expliquer avec ses mots la différence entre Git (historique local) et GitHub (service d’hébergement de dépôts).
Créer un dépôt, vérifier les fichiers avant publication et rédiger un README.
Enregistrer une modification cohérente dans un commit et expliquer ce qu’elle change.
Comparer deux versions, identifier une erreur et revenir à un état fonctionnel sans effacer son travail.
Reconnaître les risques de publication : secrets, données personnelles, licences et visibilité publique.
Plan des 10 heures
Séquence 1 — Pourquoi versionner ? Git, GitHub, sauvegarde et vocabulaire (1 h 30).
Séquence 2 — Créer un compte et un dépôt, choisir public/privé (1 h 30).
Séquence 3 — Ajouter le projet HTML/CSS/JS et écrire README.md (1 h 30).
Séquence 4 — Modifications, commits et historique (2 h).
Séquence 5 — Comparer, corriger, restaurer et branches (2 h).
Séquence 6 — Évaluation et autonomie (1 h 30).
1. Comprendre la gestion de versions
Sans historique, un fichier index-final-v2-corrigé.html devient vite difficile à suivre. Git enregistre des instantanés cohérents du projet. Un commit est un point de l’historique identifié et commenté. GitHub permet de conserver et partager un dépôt Git en ligne ; il ne remplace pas à lui seul une stratégie de sauvegarde.
Lexique : dépôt = dossier suivi par Git ; commit = enregistrement ; branche = ligne de travail ; différence (diff) = comparaison ; clone = copie locale ; push = envoi de commits vers un dépôt distant ; pull = récupération et intégration des changements distants ; rollback = retour contrôlé à une version antérieure.
Voir un exemple, essayer et vérifier
Je vois — exemple concret : Version A : la page fonctionne. Version B : vous changez le titre. Une copie datée permet de retrouver A ; un commit Git permet de retrouver un état enregistré dans un historique. Ce ne sont pas exactement les mêmes opérations.
J’essaie — petit geste : Faites une copie du fichier avant modification, changez son titre puis restaurez la copie pour constater le retour en arrière.
Je vérifie — si cela ne fonctionne pas : Ne remplacez jamais votre seule copie stable. Git est une voie complémentaire, pas un prérequis pour cette observation.
Comprendre et essayer — exemple guidé
Je vois : Comparer deux versions permet de voir précisément les changements plutôt que de se fier à sa mémoire.
J’essaie : Comparez deux versions d’un même fichier et indiquez ce qui a changé.
Je vérifie : Le fichier modifié et la différence exacte sont identifiés ; le reste du projet n’est pas confondu avec ce changement.
Autre façon de faire : Comparez les deux versions avec un outil de différence gratuit ou annotez les lignes changées.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
2. Préparer notre projet évolutif
Nous réutilisons les trois fichiers issus du module 5 : index.html, style.css et script.js. Avant toute publication, ouvrir index.html, tester les boutons, vérifier les liens et supprimer les informations privées. Un fichier de configuration contenant un mot de passe ou une clé API ne doit jamais être ajouté au dépôt.
mon-premier-projet/
index.html
style.css
script.js
README.md
.gitignore
Le fichier README.md explique ce que fait le projet et comment le lancer. Le fichier .gitignore indique à Git les fichiers locaux à ne pas suivre. Il ne supprime pas un secret déjà enregistré dans l’historique.
Comprendre et essayer — exemple guidé
Je vois : Une copie stable offre un point de retour si la modification échoue.
J’essaie : Créez une copie stable du projet avant d’introduire une modification.
Je vérifie : Une copie identifiable permet de rouvrir la version d’avant la modification.
Autre façon de faire : Dupliquez le dossier local et datez la copie avant toute modification.
Pour reprendre plus tard : Conservez votre production de l’activité 2, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
3. Première méthode : interface web GitHub
Étape 1. Se connecter à GitHub et choisir « New repository ».
Étape 2. Nommer le dépôt mon-premier-projet ; choisir sa visibilité en connaissance de cause.
Étape 3. Créer le dépôt avec un README, puis ajouter les fichiers du projet par l’interface « Add file » (les libellés peuvent évoluer).
Étape 4. Vérifier la liste des fichiers, rédiger un message précis (« Ajouter la page HTML du module 5 ») et valider le commit.
Étape 5. Ouvrir l’historique des commits, puis inspecter un changement.
Attention : un dépôt public peut être consulté et copié par d’autres. Une suppression ultérieure n’efface pas nécessairement les copies déjà réalisées.
Comprendre et essayer — exemple guidé
Je vois : L'historique d'un dépôt associe des changements à des versions identifiables.
J’essaie : Repérez les actions permettant de consulter un historique dans l’interface GitHub.
Je vérifie : L’historique permet de retrouver une modification et sa date ou son identifiant.
Autre façon de faire : Repérez sur une capture de GitHub les commandes d’historique ; l’accès réel nécessite un compte.
Pour reprendre plus tard : Conservez la version ou le scénario utilisé, la preuve disponible et l’étape distante qui reste à tester réellement.
4. Deuxième méthode : commandes Git élémentaires
Sur un ordinateur où Git est installé, ouvrir un terminal dans le dossier du projet. Les commandes ci-dessous sont expliquées une à une. Ne pas les exécuter dans un dossier contenant des documents personnels.
git init
git status
git add index.html style.css script.js README.md
git commit -m "Créer la première version du site"
git log --oneline
git diff
git init : démarre le suivi du dossier.
git status : indique ce qui a changé et ce qui est prêt à être enregistré.
git add : prépare les fichiers désignés pour le prochain commit.
git commit : enregistre l’instantané préparé avec un message.
git log --oneline : affiche l’historique condensé.
git diff : montre les changements non préparés ; git diff --staged montre ceux déjà préparés. Juste après un commit, si aucun fichier n’a été modifié, git diff n’affiche rien : c’est normal. Pour examiner un commit enregistré, utiliser git show --stat HEAD ou git show HEAD.Faire défiler horizontalement pour voir les lignes longues.
Pour le premier commit, Git peut demander une identité : exécuter git config --local user.name "Apprenant" puis git config --local user.email "apprenant@example.invalid" (identité fictive uniquement pour l’exercice local). Ne pas publier une identité fictive en prétendant qu’elle est réelle. Selon la configuration, Git peut demander un nom et une adresse électronique avant le premier commit. L’envoi vers GitHub demande en plus de configurer un dépôt distant et une authentification adaptée ; la méthode web est suffisante pour le premier TP.
Comprendre et essayer — exemple guidé
Je vois : Init prépare un dépôt, status décrit l'état, add prépare les changements et commit les enregistre.
J’essaie : Associez init, status, add et commit à leur effet sans exécuter de commande destructive.
Je vérifie : Les quatre commandes sont associées à des effets distincts ; add ne signifie pas commit.
Autre façon de faire : Associez les quatre commandes à leur fonction sur papier, sans les exécuter.
Pour reprendre plus tard : Gardez le tableau de classement avec les éléments qui vous ont fait hésiter et la distinction à revoir.
5. Atelier guidé : une modification, un commit
Ouvrir index.html du projet fil rouge : dans le modèle du module 3, le titre visible h1 est « Mon espace de découverte » (ou sa version personnalisée par l’apprenant). Le modifier en « Mon projet numérique interactif ». Actualiser la page dans le navigateur, exécuter git diff avant git add pour constater le changement, puis git add index.html et git diff --staged pour vérifier exactement ce qui sera enregistré. Créer ensuite un commit nommé « Clarifier le titre de la page ». Le commit doit concerner uniquement cette modification.
Question : pourquoi ne pas enregistrer dans le même commit un changement de titre, une correction CSS et la suppression d’un fichier sans rapport ? Réponse attendue : un commit ciblé se comprend, se teste et se restaure plus facilement.
6. Diagnostiquer une régression et revenir en arrière
Situation : après un changement de script.js, le bouton ne réagit plus. 1) Reproduire l’erreur dans le navigateur. 2) Consulter git diff ou l’onglet de comparaison GitHub. 3) Repérer la ligne modifiée. 4) Corriger l’erreur et enregistrer un nouveau commit. 5) Retester sur mobile et ordinateur.
Si le problème n’est pas compris, travailler sur une copie ou une branche de test. Pour annuler un commit déjà partagé, préférer une opération qui conserve une trace (par exemple git revert avec accompagnement), plutôt qu’une réécriture destructrice de l’historique. Éviter git reset --hard sur un projet contenant du travail non sauvegardé.
Comprendre et essayer — exemple guidé
Je vois : Restaurer exige d'identifier une version fonctionnelle et la modification fautive.
J’essaie : Reproduisez une erreur mineure, puis identifiez la dernière version fonctionnelle.
Je vérifie : La dernière version fonctionnelle est identifiée et la modification fautive est isolée.
Autre façon de faire : Sur une copie locale, provoquez une petite erreur et restaurez la version conservée.
Pour reprendre plus tard : Conservez votre production de l’activité 5, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
7. Branches et pull requests : première découverte
Une branche permet d’essayer une modification sans changer immédiatement la version principale. Une pull request propose de fusionner les changements après comparaison et revue. Dans notre exercice, une branche « essai-couleurs » servira à tester une variante de style.css, puis à expliquer ce qui doit être vérifié avant fusion.
Comprendre et essayer — exemple guidé
Je vois : Une branche isole des modifications avant leur revue et leur intégration.
J’essaie : Dessinez une branche de travail et le moment où une proposition de fusion doit être relue.
Je vérifie : La branche et la revue avant fusion figurent sur le schéma, sans fusion automatique implicite.
Autre façon de faire : Dessinez la branche et la revue avant fusion ; cela ne simule pas les droits du dépôt.
Pour reprendre plus tard : Conservez le schéma annoté et indiquez quel lien ou quelle étape doit encore être confirmé lors d’un essai.
8. Étude de cas : conserver une version stable des Récits Vivants
Dans un projet narratif interactif, une amélioration peut affecter les liens, les animations ou la mémoire du visiteur. Avant modification, identifier la version stable, décrire le changement attendu, tester la nouvelle version et conserver la possibilité de restaurer l’ancienne. Git aide à retracer les changements ; il ne garantit pas que l’expérience reste cohérente sur le plan artistique.
Comprendre et essayer — exemple guidé
Je vois : Un message de version utile explique ce qui a changé et pourquoi.
J’essaie : Rédigez un message de version décrivant un changement réel de la page Récits Vivants.
Je vérifie : Le message nomme le fichier ou comportement modifié et le résultat obtenu.
Autre façon de faire : À partir d’une modification réellement effectuée sur votre copie locale, rédigez un message de version qui précise le fichier et le changement. Sans modification réelle, indiquez qu’il s’agit d’un exercice fictif.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
9. Travaux pratiques et corrigés
TP1 — Dessiner le cycle : modifier → comparer → tester → commit.
Consigne : réaliser la tâche, noter les étapes et fournir une capture ou une explication écrite.
Corrigé : le commit vient après comparaison et test ; un nouveau changement relance le cycle.
Approfondissement guidé — TP1
Consigne : Dessinez cinq cases reliées : modifier, comparer, tester, enregistrer un commit, vérifier l’historique. Ajoutez une flèche de retour vers « modifier » lorsqu’un test échoue. Expliquez en deux phrases pourquoi un commit n’est pas un test.
Livrable : Un schéma lisible et deux phrases d’explication.
Afficher le corrigé commenté
Ordre attendu : modifier → comparer les différences → tester → commit → consulter l’historique. Si le test échoue, corriger avant le commit. Un commit conserve un état, il ne garantit pas que cet état fonctionne.
Pourquoi cette réponse ? La bonne séquence distingue le changement, sa comparaison, sa vérification et son enregistrement : un commit n’est pas un test.
Exemple ou vérification autonome Modifiez un titre, examinez git diff, testez dans le navigateur puis consultez git log après commit.
Comprendre et essayer — exemple guidé
Je vois : Une trace de modification doit permettre d'identifier son contenu et son auteur.
J’essaie : Vérifiez que le premier TP laisse une trace du changement et de son auteur.
Je vérifie : La trace précise le changement, son auteur et un état vérifiable du projet.
Autre façon de faire : Conservez une copie avant/après et notez la preuve du changement ; sans dépôt, ne prétendez pas avoir créé un commit.
Pour reprendre plus tard : Notez le résultat attendu, l’observation obtenue et l’éventuel écart à reproduire à la prochaine séance.
TP2 — Écrire un README : objectif, trois fichiers, mode d’ouverture et limites.
Consigne : réaliser la tâche, noter les étapes et fournir une capture ou une explication écrite.
Corrigé : une autre personne doit comprendre le projet et ouvrir index.html sans explication orale.
Approfondissement guidé — TP2
Consigne : Rédigez un README.md pour un mini-site composé de index.html, style.css et script.js. Précisez son objectif, les fichiers, comment l’ouvrir, les limites et une vérification manuelle. N’inventez pas de fonctionnalités.
Livrable : README.md avec cinq rubriques utiles.
Afficher le corrigé commenté
Exemple : « Objectif : présenter un projet ; fichiers : index.html (structure), style.css (apparence), script.js (interaction) ; ouverture : double-cliquer index.html ; limites : pas de compte utilisateur ; test : ouvrir la page et activer le bouton ». Un bon README permet à un tiers de reproduire l’ouverture.
TP3 — Identifier cinq fichiers qui ne devraient pas être publiés.
Consigne : réaliser la tâche, noter les étapes et fournir une capture ou une explication écrite.
Corrigé indicatif : mot de passe, clé API, fichier de données clients, export personnel, configuration secrète.
Approfondissement guidé — TP3
Consigne : Dans cette liste, repérez ce qui ne doit pas être publié : index.html, mot-de-passe.txt, .env, photo-privee.jpg, style.css, sauvegarde-clients.csv, script.js, cle-api.json, notes-medicales.txt. Justifiez vos choix. Rédigez trois règles de vérification avant tout dépôt public.
Livrable : Liste argumentée des fichiers sensibles et trois règles.
Afficher le corrigé commenté
À exclure : mot-de-passe.txt, .env (s’il contient des secrets), photo-privee.jpg, sauvegarde-clients.csv, cle-api.json, notes-medicales.txt. Les fichiers HTML/CSS/JS ne sont pas automatiquement sûrs : les inspecter aussi. Règles : relire les fichiers, rechercher les secrets, vérifier la visibilité du dépôt. .gitignore aide mais ne retire pas un secret déjà publié.
Corrigé indicatif : mot de passe, clé API, fichier de données clients, export personnel, configuration secrète.
Comprendre et essayer — exemple guidé
Je vois : La comparaison avant/après montre si une manipulation a produit l'effet annoncé.
J’essaie : Comparez l’état du projet avant et après la troisième manipulation.
Je vérifie : La comparaison distingue ce qui a changé de ce qui doit rester inchangé.
Autre façon de faire : Comparez deux fichiers locaux et consignez la modification observée.
Pour reprendre plus tard : Notez le résultat attendu, l’observation obtenue et l’éventuel écart à reproduire à la prochaine séance.
TP4 — Provoquer volontairement une erreur de texte, retrouver la différence et la corriger.
Consigne : réaliser la tâche, noter les étapes et fournir une capture ou une explication écrite.
Corrigé : observer le diff, identifier la modification exacte, réparer et retester.
Approfondissement guidé — TP4
Consigne : Créez une page simple et conservez une copie stable. Changez volontairement un titre en supprimant une lettre. Comparez les versions, identifiez la ligne modifiée, restaurez le titre et vérifiez dans le navigateur. Si vous utilisez Git, créez un commit après réparation ; sinon documentez le cycle sans compte.
Livrable : Avant/après, différence identifiée et résultat du test.
Afficher le corrigé commenté
La différence doit montrer exactement la modification du texte ; après correction, le titre est de nouveau conforme. Le test visuel confirme le rendu. Pour éviter de perdre d’autres modifications, restaurer uniquement la ligne concernée plutôt que tout le dossier.
Comprendre et essayer — exemple guidé
Je vois : Le suivi des fichiers modifiés facilite la restauration ciblée.
J’essaie : Repérez le fichier précis touché par le quatrième TP et la manière de le restaurer.
Je vérifie : Le fichier touché est nommé et une copie ou version antérieure est disponible.
Autre façon de faire : Identifiez le fichier modifié et décrivez comment le restaurer depuis la copie stable.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
TP5 — Créer une branche d’essai et expliquer sa différence avec la branche principale.
Consigne : réaliser la tâche, noter les étapes et fournir une capture ou une explication écrite.
Corrigé : la branche isole un travail expérimental jusqu’à sa revue et sa fusion éventuelle.
Approfondissement guidé — TP5
Consigne : Décrivez ou réalisez le scénario suivant : une page stable est conservée sur main ; une variante de navigation est développée sur essai-navigation. Comparez les changements, notez deux tests, puis expliquez quand proposer une pull request. Sans compte GitHub, produisez le schéma et un message de proposition.
Livrable : Schéma des deux branches, deux tests et message de proposition.
Afficher le corrigé commenté
main reste la référence stable ; essai-navigation contient les changements à vérifier. La pull request propose une revue avant fusion, elle n’est pas une publication automatique. Exemples de tests : liens actifs et navigation au clavier. Ne fusionner qu’après revue et correction des défauts.
Comprendre et essayer — exemple guidé
Je vois : Une preuve de fonctionnement peut être un test reproductible ou une capture accompagnée d'étapes.
J’essaie : Décrivez le résultat du cinquième TP et sa preuve de fonctionnement.
Je vérifie : Le résultat attendu du TP est décrit avec une preuve vérifiable (diff, fichier ou capture).
Autre façon de faire : Notez le résultat du TP et sa preuve ; effectuez le contrôle réel dans une copie locale.
Pour reprendre plus tard : Conservez votre production de l’activité 11, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
Entraînement interactif facultatif — V0.6.0
Ces questions complémentaires ne constituent ni une note ni une validation de compétence. Aucune réponse n’est enregistrée.
10. Autoévaluation : dix questions
1. Git et GitHub sont-ils identiques ?
Afficher le corrigé
Réponse : Non : Git est un système de gestion de versions ; GitHub héberge des dépôts et propose des outils de collaboration.
Pourquoi cette réponse ? Git suit l’historique local ; GitHub fournit un service distant de dépôts et de collaboration. Les deux ne sont pas synonymes.
Exemple ou vérification autonome Créez un dépôt Git local et constatez qu’aucun compte GitHub n’est nécessaire.
2. Qu’est-ce qu’un dépôt ?
Afficher le corrigé
Réponse : Un ensemble de fichiers et leur historique Git.
Pourquoi cette réponse ? Un dépôt rassemble les fichiers suivis et leur historique ; un dossier ordinaire ne possède pas automatiquement cet historique.
Exemple ou vérification autonome Exécutez git status dans un dépôt et comparez avec un dossier non initialisé.
3. Qu’est-ce qu’un commit ?
Afficher le corrigé
Réponse : Un enregistrement identifié d’un état préparé du projet.
Pourquoi cette réponse ? Un commit fige un ensemble de modifications préparées avec un identifiant ; il ne prouve pas que le programme fonctionne.
Exemple ou vérification autonome Faites un petit commit puis affichez son contenu avec git show HEAD.
4. Que montre un diff ?
Afficher le corrigé
Réponse : Les changements entre deux états.
Pourquoi cette réponse ? Un diff met en évidence les ajouts et retraits entre états, pour examiner précisément ce qui a changé.
Exemple ou vérification autonome Changez une ligne et inspectez git diff avant de l’enregistrer.
5. Pourquoi tester avant un commit ?
Afficher le corrigé
Réponse : Pour éviter de considérer une version défectueuse comme validée.
Pourquoi cette réponse ? Tester avant le commit évite d’inscrire comme étape de référence un état dont le comportement est déjà connu comme défectueux.
Exemple ou vérification autonome Introduisez une erreur de lien, testez, corrigez, puis seulement enregistrez le commit.
6. Que fait git status ?
Afficher le corrigé
Réponse : Il montre l’état des fichiers suivis, modifiés ou préparés.
Pourquoi cette réponse ? git status renseigne sur les fichiers modifiés, non suivis ou préparés ; il ne valide pas le contenu du code.
Exemple ou vérification autonome Comparez git status avant et après git add index.html.
7. À quoi sert un README ?
Afficher le corrigé
Réponse : À présenter le projet et les instructions de démarrage.
Pourquoi cette réponse ? Le README aide un tiers à comprendre le projet et à le lancer sans deviner son organisation.
Exemple ou vérification autonome Rédigez un README avec objectif, fichiers nécessaires et mode d’ouverture.
8. Peut-on publier une clé API dans un dépôt privé ?
Afficher le corrigé
Réponse : Non : le caractère privé réduit l’exposition mais ne justifie pas d’y placer des secrets.
Pourquoi cette réponse ? Un dépôt privé limite l’accès, mais un secret enregistré peut fuiter ou être partagé par erreur ; il doit rester hors du suivi.
Exemple ou vérification autonome Vérifiez qu’aucun jeton ni mot de passe ne figure dans les fichiers préparés au commit.
9. Pourquoi créer une branche ?
Afficher le corrigé
Réponse : Pour isoler un changement ou un essai.
Pourquoi cette réponse ? Une branche isole un essai pour le comparer avant de l’intégrer ; elle n’est pas une sauvegarde indépendante.
Exemple ou vérification autonome Créez une branche de test et vérifiez la différence avec la branche principale.
10. Comment traiter une régression après publication ?
Afficher le corrigé
Réponse : Reproduire, comparer, corriger ou annuler de façon traçable, puis retester.
Pourquoi cette réponse ? La traçabilité permet de comprendre l’origine d’une panne et de revenir à une version saine sans masquer les changements.
Exemple ou vérification autonome Repérez le commit fautif, restaurez le comportement puis consignez le test de confirmation.
11. Épreuve d’autonomie (sans IA) — 45 minutes
À partir des trois fichiers fournis : créer un dépôt, écrire un README, effectuer deux changements distincts, créer deux commits explicites, retrouver les différences et expliquer oralement comment revenir à une version fonctionnelle. L’évaluation porte sur les preuves de compréhension, pas seulement sur la présence d’un dépôt.
Barème sur 20 : structure du dépôt et README (4), commits cohérents (4), lecture de l’historique et des différences (4), diagnostic et retour à un état stable (5), sécurité et explication autonome (3). Réussite visée : 14/20 et aucune publication de secret.
Comprendre et essayer — exemple guidé
Je vois : Retrouver une version stable ne nécessite pas d'assistant IA si l'historique est lisible.
J’essaie : Sans IA, retrouvez une version stable et justifiez votre choix.
Je vérifie : La version choisie est associée à une preuve de fonctionnement, pas seulement à sa date.
Autre façon de faire : Sans IA, comparez les copies disponibles et expliquez pourquoi l’une est stable.
Pour reprendre plus tard : Conservez uniquement l’exemple anonymisé, la correction retenue et l’affirmation ou la donnée qu’il faudra contrôler.
12. Transition vers le module 7 — Codex
Le projet du module 6 servira de support à un assistant IA de développement (Codex étant un exemple). Sans accès direct au dépôt ou aux fichiers, fournir uniquement les extraits nécessaires, examiner les propositions puis effectuer soi-même les modifications dans l’éditeur. Avant d’accepter une modification générée par IA, l’apprenant devra pouvoir lire les différences, tester le résultat et enregistrer une version traçable. GitHub sera ainsi un outil de contrôle et non une simple destination de fichiers.
Comprendre et essayer — exemple guidé
Je vois : Une demande d'aide fiable précise les fichiers concernés et les tests à préserver.
J’essaie : Notez les fichiers et tests à transmettre avant de demander une aide à Codex.
Je vérifie : La demande d’aide liste les fichiers nécessaires et un test de reproduction sans divulguer de secrets.
Autre façon de faire : Préparez sur papier la liste des fichiers, le résultat attendu et les tests avant de solliciter Codex.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
Atelier d’approfondissement — parcours guidé
Ce parcours complète les travaux pratiques du module. Il peut être réalisé sans abonnement payant et ne constitue pas une évaluation certifiante.
Ce que vous allez apprendre — Sauvegarder une version, identifier un changement et restaurer l’état précédent.
Matériel nécessaire — Ordinateur et gestionnaire de fichiers ; Git facultatif.
Organisation sur deux écrans — Vous pouvez lire ce cours sur téléphone et effectuer les manipulations sur ordinateur. Gardez les deux appareils à portée de vue ; aucun transfert de données entre eux n’est obligatoire.
Créer une version récupérable
Comment procéder concrètement
- Copiez le dossier de projet dans un dossier de sauvegarde nommé avant-modification.
- Dans la copie de travail, modifiez uniquement le texte du lien Programme.
- Ouvrez les deux fichiers côte à côte et repérez la ligne différente.
- Testez la copie modifiée dans le navigateur et consignez le résultat.
- Sur une copie d’essai, remettez le fichier initial et vérifiez que l’ancien libellé réapparaît.
Si vous n’avez qu’un téléphone — Sur téléphone, vous pouvez comparer deux versions d’un texte ; pour restaurer un projet multi-fichiers, un ordinateur est recommandé.
Repères pratiques — Revenir en arrière sans risque
À réaliser concrètement : Avant toute modification, dupliquez le dossier du projet. Pour Git, si déjà installé, utilisez git status pour voir les changements et git diff pour les comparer. Pour revenir sur une modification non enregistrée dans Git, restaurez le fichier depuis votre copie datée. N’exécutez aucune commande de réinitialisation destructive dans cet atelier.
Si vous êtes bloqué : Si vous ne retrouvez pas la version initiale, arrêtez-vous : ne remplacez pas les fichiers au hasard. Recherchez la copie datée.
Essai autonome, sans recopier le modèle : Modifiez une phrase différente, comparez les deux versions, puis restaurez la phrase initiale.
Étape 1 — Conserver l’état initial
À faire : Copiez le projet dans un dossier sauvegarde-avant-changement ou créez un commit Git.
Exemple ou résultat modèle : Une copie datée ou un commit nommé « Ajouter le lien vers le programme ».
Vérification : Vous savez retrouver l’état précédent.
Étape 2 — Modifier une seule chose
À faire : Changez le texte d’un lien et comparez les fichiers.
Exemple ou résultat modèle : Avant : « Programme » ; après : « Consulter le programme ».
Vérification : La modification correspond à l’objectif annoncé.
Étape 3 — Revenir en arrière
À faire : Restaurez le fichier d’origine sur une copie d’essai.
Exemple ou résultat modèle : Le lien retrouve son libellé initial.
Vérification : Les autres fichiers restent inchangés.
Si cela ne fonctionne pas : pistes de dépannage
Vous avez modifié la sauvegarde : recommencez avec deux dossiers distincts. Le retour arrière échoue : vérifiez que vous avez restauré le bon index.html.
Afficher le corrigé commenté
Corrigé modèle : une bonne version comprend un état identifiable, une description précise et une procédure de retour arrière. La copie manuelle constitue une alternative sans compte.
Exemple complet à reproduire
Fichier ou livrable modèle : journal-versionnement.txt. Copiez ou adaptez ce contenu dans votre propre dossier de travail.
ÉTAT DE DÉPART : index.html et style.css fonctionnels.
SAUVEGARDE : copie locale projet-avant-lien/ (ou commit Git).
MODIFICATION : libellé du lien « Programme » → « Consulter le programme ».
CONTRÔLE : comparer uniquement index.html, puis ouvrir la page.
PREUVE : capture ou note indiquant le nouveau libellé et le lien actif.
RETOUR ARRIÈRE : restaurer index.html depuis la copie de référence.
RÉSULTAT ATTENDU : ancien libellé restauré, CSS inchangé.
OPTION GIT (si installé et configuré) :
git status
git add index.html
git commit -m "Clarifier le libellé du lien programme"
git diff HEAD~1 HEAD -- index.htmlPourquoi ce corrigé est valable
La sauvegarde précède la modification. La comparaison porte sur un fichier ciblé et le retour arrière est décrit avant d'être nécessaire. Les commandes Git sont une option ; une copie locale datée suffit pour cet exercice.
Preuve de vérification attendue
Après réalisation, conservez le fichier produit et une note indiquant la manipulation testée, le résultat réellement observé et les éventuelles limites. Ne cochez pas un test non effectué.
Bilan personnel : notez ce qui fonctionne, ce qui reste à vérifier et une amélioration possible. Aucun résultat de cet atelier n’est envoyé au site.
Complément de corrigé TP — exemple de vérification et diagnostic
Sauvegarde et version — Conserver une copie identifiée avant toute modification, provoquer une modification mineure, puis restaurer la version précédente et comparer le résultat.
Variante autonome : changer un seul élément de votre réalisation, prévoir le résultat, effectuer le test et consigner ce qui a réellement été observé. Plusieurs solutions sont acceptables si elles satisfont les critères du TP.
Laboratoire ludique facultatif — La machine à remonter les versions
Modifie une page fictive, compare le travail en cours à un commit, explore l'historique et restaure une version sans effacer les autres. Simulation locale, sans GitHub ni score.