Choisir un flux de branches

Ce que vous saurez faire

Un pipeline doit savoir quelle branche contient le code qui peut aller en production. Choisissez un flux de branches qui répond à cette question. Ensuite, écrivez la source et la cible de chaque demande de tirage. Ainsi, personne ne fusionne dans le mauvais sens.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 45 minutes

Ce que vous devez savoir

• Une branche est une étiquette sur un commit (un enregistrement des changements), selon Bases des branches : une branche est une étiquette sur un commit dans L’essentiel de Git et du développement en équipe.
• Une demande de tirage (pull request) a une source et une cible, selon Les étapes d’une demande de tirage : ce qu’est une demande de tirage dans le cours sur Git.
• Les commits de fusion, selon Stratégies de fusion : une branche, trois façons de l’intégrer à main dans le cours sur Git.
• Les branches de version, les étiquettes et les numéros de version, selon Branches de version et étiquettes : l’équipe publie une version et Numéros de version dans le cours sur Git.
• Un correctif sur une version, fusionné dans main, selon Garder des historiques cohérents : deux endroits, un correctif dans le cours sur Git.
• Le pipeline et son vocabulaire, selon Du commit à la mise en production : le vocabulaire, sur le vrai pipeline.

Ce qu’il vous faut sur votre ordinateur

• Git, selon Configurer Git : Étape 1 : vérifier que Git est installé dans le cours sur Git. La pratique guidée clone le dépôt de référence public dans un nouveau dossier d’exercice, ~/projects/c19-reference. Elle ne modifie pas votre propre projet.
• Votre API de billets de soutien du cours L’essentiel de Docker et du nuage pour les développeurs en IA, dans ~/projects/ticket-api. Cette leçon ne la modifie pas. Si elle manque, copiez l’instantané end-of-m05 du cours sur Docker, comme dans Utiliser un instantané.

Exécuté avec GitHub Actions (exécuteurs ubuntu-24.04) dans le dépôt public Nextia-Intelligence/ticket-api-ci. Les commandes Git ont été exécutées avec Git 2.54 sur macOS. Les étapes Windows ne sont pas testées.

Deux questions pour chaque changement

Avant d’écrire une ligne de code, Amira répond à deux questions. Où commence le changement? Où va-t-il? Une demande de tirage donne les réponses avec sa branche source et sa branche cible : « feature/classifier-1.1 vers main ».

Un flux de branches définit les règles de l’équipe pour ces réponses. Quelles branches existent, à quoi chacune sert, d’où chacune part et où elle est fusionnée. Un pipeline dépend de ces règles. Il doit savoir quelle branche construire pour la production, et quelles branches reçoivent seulement des vérifications. Deux flux sont courants.

Développement sur la branche principale

Dans le développement sur la branche principale (aussi appelé développement basé sur le tronc), main est la seule branche durable. Elle est toujours prête pour une mise en production. Chaque changement commence sur une branche temporaire créée à partir de main. Il retourne dans main par une demande de tirage. Une mise en production correspond à une étiquette sur un commit de main.

Voici l’historique réel du dépôt de référence, du début à la version 1.2.0 :

L'historique réel de Nextia-Intelligence/ticket-api-ci, du début à v1.2.0. Chaque branche de fonctionnalité dure quelques minutes à quelques heures et contient un changement. Les étiquettes sont sur les commits de fusion de main.

Description textuelle du diagramme

main commence avec quatre commits. Ensuite, chaque changement a sa propre branche issue de main : feature/deploy, feature/release-tags, feature/classifier-1.1 et feature/score-field. Chaque branche a un commit et retourne dans main avec un commit de fusion, par les demandes de tirage 1, 2, 3 et 5. L’étiquette v1.1.0 est sur la fusion de la PR nº 2. L’étiquette v1.2.0 est sur la fusion de la PR nº 5.

Observez trois choses :

• Un changement par branche. Chaque branche de fonctionnalité a un commit et retourne dans main en moins d’une heure. Une branche temporaire a peu de conflits, et sa demande de tirage est assez petite pour être révisée.
• Aucune branche n’attend une mise en production. main reçoit chaque changement terminé. Le pipeline construit chaque commit de main une seule fois. Chaque commit de main a donc une image qui peut aller en production.
• Une mise en production correspond à une étiquette, pas à une branche. v1.1.0 et v1.2.0 pointent vers des commits de main. Rien n’a été copié dans une autre branche pour les créer.

Les premiers commits (da4e3f3, 399c0d2, c862935) sont allés dans main sans demande de tirage. À ce moment, le dépôt n’avait pas encore d’ensemble de règles : le module 2 l’ajoute. À partir de la PR nº 1, chaque changement est passé par une demande de tirage.

La PR nº 4 n’est pas dans le graphe. Sa source était feature/fewer-urgent-tickets, et sa cible, main. Ses vérifications ont échoué, alors Amira l’a fermée sans fusion (la leçon 3 explique pourquoi). Ses commits n’ont jamais atteint main, donc git log main ne les affiche pas. C’est le but de la barrière.

Branches de version

Avec les branches de version, l’équipe crée une branche comme release/1.2 à partir de main quand la prochaine version est prête. La branche de version reçoit seulement des correctifs, tandis que le nouveau travail continue sur main. Chaque mise en production correspond à une étiquette sur la branche de version. Les correctifs sont ensuite fusionnés dans main. Le cours sur Git a enseigné ce flux. GitFlow est une variante connue : elle ajoute une branche develop pour le nouveau travail et réserve main aux versions publiées.

Le même type d’historique avec une branche de version ressemblerait à ceci. C’est un exemple, pas le dépôt de référence :

Un exemple de branches de version. La version 1.2 reste sur release/1.2, sans la fonctionnalité C. Chaque correctif sur la version doit être fusionné dans main.

Description textuelle du diagramme

Dans cet exemple, main contient les fonctionnalités A et B. L’équipe crée release/1.2 à partir de la fonctionnalité B. La version ne contient donc pas la fonctionnalité C, encore en cours sur sa propre branche. La branche de version reçoit un correctif de test, étiqueté v1.2.0, puis un correctif urgent, étiqueté v1.2.1. La fonctionnalité C est fusionnée dans main. Ensuite, la branche de version est fusionnée dans main pour ne pas perdre les deux correctifs. main continue avec la fonctionnalité D.

Quel flux convient

	Développement sur la branche principale	Branches de version
Branches durables	main seulement	main et une branche pour chaque version prise en charge
Origine d’une mise en production	Une étiquette sur main	Une étiquette sur release/x.y
Un correctif pour la production	Une demande de tirage normale vers main, ou une branche de correctif urgent issue de l’étiquette	Une demande de tirage vers release/x.y, puis une fusion dans main
Ce que le pipeline construit pour la production	Chaque commit de main	Chaque commit de chaque branche de version
Convient quand	Un seul service déployé, de petits changements, plusieurs déploiements par semaine	Plusieurs versions utilisées en même temps, ou des mises en production lentes : une application qui attend la révision d’une boutique, un logiciel que les clients installent eux-mêmes, une longue phase de test
Risque	Le travail inachevé sur main ne doit pas atteindre les utilisateurs : gardez-le petit, ou masquez-le avec un paramètre	Un correctif sur la version est oublié sur main et revient comme bogue dans la prochaine version

L’API de billets est un seul service avec un seul environnement de production. L’équipe déploie plusieurs fois par jour, et chaque changement est petit. Les utilisateurs n’exécutent jamais une ancienne version : le service de soutien utilise l’unique déploiement. Le cours utilise donc le développement sur la branche principale.

Deux règles gardent main prête pour une mise en production :

1. Chaque changement sur main a réussi les vérifications. L’ensemble de règles du module 2 exige une demande de tirage avec des vérifications au vert.
2. Le travail inachevé est désactivé. La PR nº 3 a placé le nouveau classificateur sur main avec CLASSIFIER_VERSION=1.0 comme valeur par défaut. La production se comportait donc comme avant. Le module 4 l’active progressivement.

Il reste une exception : un correctif urgent quand main contient déjà des changements qui ne sont pas prêts pour la production. L’équipe utilise alors une branche de correctif urgent temporaire, créée à partir de l’étiquette de version. C’est le seul cas où une branche ne part pas de main. Le dépôt de référence l’a fait une fois :

Le vrai correctif urgent : hotfix/1.2.1 part de l'étiquette v1.2.0, pas du dernier état de main. L'étiquette v1.2.1 est sur la branche de correctif urgent. La PR nº 7 fusionne le correctif dans main.

Description textuelle du diagramme

Après v1.2.0, main a reçu la PR nº 6, feature/local-platform. La production exécutait encore v1.2.0 et avait un bogue. La branche de correctif urgent hotfix/1.2.1 part du commit de l’étiquette v1.2.0. Elle ne contient donc pas la PR nº 6. Son commit fc9005a contient le correctif et l’étiquette v1.2.1. Ensuite, main est fusionnée dans la branche de correctif urgent (543b003), car l’ensemble de règles exigeait une branche à jour. Puis la PR nº 7 fusionne hotfix/1.2.1 dans main (3464f2c). Enfin, la PR nº 8 ajoute feature/backfill-score.

Pourquoi partir de l’étiquette? La production exécutait v1.2.0. Un correctif urgent doit corriger seulement le bogue. Il part donc exactement de ce que la production exécute. S’il partait du dernier état de main, il amènerait aussi la PR nº 6 en production sans sa propre mise en production. Le module 5 enseigne la procédure complète de correctif urgent. Ce module la situe seulement dans le flux.

Versions et étiquettes

Un numéro de version indique aux utilisateurs ce qu’ils peuvent attendre d’une mise en production. L’API de billets utilise le versionnage sémantique : MAJOR.MINOR.PATCH, comme dans le cours sur Git. Pour une API, une « rupture de compatibilité » signifie qu’un client qui fonctionnait auparavant peut maintenant échouer :

Changement dans le dépôt de référence	Version	Pourquoi
La première mise en production par le pipeline	1.1.0	La version de départ du cours sur Docker.
Nouveau champ score dans chaque réponse; confidence reste, marqué comme désuet	1.1.0 → 1.2.0	MINOR : ajout, et les anciens clients fonctionnent encore.
Correctif : GET /v1/history échouait avec des lignes de la version 1.1.0	1.2.0 → 1.2.1	PATCH : un correctif seulement.
Prévu : supprimer confidence	→ 2.0.0	MAJOR : les clients qui lisent confidence ne fonctionnent plus.

Deux choses différentes s’appellent une étiquette dans ce cours :

• Une étiquette Git est un nom fixe pour un commit : v1.2.0 → c3c7135. Elle ne change jamais de cible.
• Une étiquette d’image est un nom pour une image dans le registre : ghcr.io/usmanahmed99/ticket-api-ci:1.2.0, et sha-c3c7135 pour la même image. Le flux de mise en production donne l’étiquette de version à l’image quand vous poussez l’étiquette Git. L’empreinte de l’image identifie son contenu. Une étiquette peut être déplacée vers une autre empreinte.

Le dépôt de référence utilise des étiquettes annotées, qui conservent un message, une date et la personne qui les a créées. git tag -a v1.2.0 -m "…" en crée une. La pratique guidée montre leurs messages.

Exemple détaillé : lire l’historique réel

Amira veut savoir quelles versions contiennent la PR nº 3, et si le correctif urgent a atteint main. Git répond aux deux questions à partir d’un clone. Elle clone le dépôt public dans un dossier d’exercice :

macOS et Linux

Terminal

cd ~/projects
git clone https://github.com/Nextia-Intelligence/ticket-api-ci.git c19-reference
cd c19-reference
git log --oneline --first-parent main

Windows

PowerShell (not tested)

cd $HOME\projects
git clone https://github.com/Nextia-Intelligence/ticket-api-ci.git c19-reference
cd c19-reference
git log --oneline --first-parent main

--first-parent (premier parent seulement) suit uniquement les commits faits sur main elle-même et exclut les commits des branches. La sortie :

30e0c7e Merge pull request #8 from usmanahmed99/feature/backfill-score
3464f2c Merge pull request #7 from usmanahmed99/hotfix/1.2.1
6ae49dc Merge pull request #6 from usmanahmed99/feature/local-platform
c3c7135 Merge pull request #5 from usmanahmed99/feature/score-field
7324d7b Merge pull request #3 from usmanahmed99/feature/classifier-1.1
92fff66 Merge pull request #2 from usmanahmed99/feature/release-tags
43de57b Merge pull request #1 from usmanahmed99/feature/deploy
c862935 Fix the two lint findings: raise ... from None, and sort the imports
399c0d2 Add the CI pipeline: lint, tests, audit, then build, smoke-test and push the image
da4e3f3 Describe the delivery path: branches, checks and promotion
df1d2a8 Start from C18: ticket-api 1.1.0 in a container

Chaque ligne après c862935 est une fusion de demande de tirage, et chaque message nomme sa source. C’est le développement sur la branche principale, lu dans l’historique. Ensuite, les étiquettes :

Terminal

git tag -n1
git tag --contains 7324d7b

La sortie :

v1.1.0          ticket-api 1.1.0: the first release through the pipeline
v1.2.0          ticket-api 1.2.0: score next to confidence; classifier keywords-1.1 (off by default)
v1.2.1          ticket-api 1.2.1: hotfix for GET /v1/history with rows from 1.1.0
v1.2.0
v1.2.1

Les trois premières lignes sont les étiquettes avec leurs messages. Les deux dernières répondent à la question : le commit de fusion 7324d7b de la PR nº 3 est dans v1.2.0 et v1.2.1, mais pas dans v1.1.0. Maintenant, le correctif urgent :

Terminal

git branch -a --contains fc9005a
git tag --contains 5893093

La sortie :

* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/hotfix/1.2.1
  remotes/origin/main

Le commit de correctif urgent fc9005a est sur main. La prochaine mise en production depuis main conserve donc le correctif. La deuxième commande n’a rien affiché : aucune étiquette ne contient 5893093, le commit de la PR nº 6. La version 1.2.1 a été créée à partir de v1.2.0. Elle ne contient donc pas la PR nº 6. C’est correct pour un correctif urgent. Cela signifie aussi qu’un correctif sur main atteint les utilisateurs seulement lors de la prochaine mise en production depuis main.

La liste des branches sur GitHub montre le même flux sous un autre angle :

Il ne reste que deux branches. Chaque branche de fonctionnalité a été supprimée quand sa demande de tirage a été fusionnée ou fermée. hotfix/1.2.1 a 3 commits de retard et 0 d'avance sur main : tout son contenu est déjà sur main. L’image est en anglais.

0 ahead (0 commit d’avance) est la preuve dans le navigateur : la branche de correctif urgent n’a aucun commit absent de main.

Écrire la source et la cible

Une demande de tirage avec la mauvaise cible fusionne un changement au mauvais endroit. Écrivez les deux noms chaque fois, dans cet ordre : « source vers cible ». Voici les vraies demandes de tirage :

PR	Source	Cible	Résultat
#1	feature/deploy	main	fusionnée, 43de57b
#2	feature/release-tags	main	fusionnée, 92fff66, étiqueté v1.1.0
#3	feature/classifier-1.1	main	fusionnée, 7324d7b
#4	feature/fewer-urgent-tickets	main	fermée : une vérification a échoué
#5	feature/score-field	main	fusionnée, c3c7135, étiqueté v1.2.0
#6	feature/local-platform	main	fusionnée, 6ae49dc
#7	hotfix/1.2.1	main	fusionnée, 3464f2c (l’étiquette v1.2.1 est sur la branche, fc9005a)
#8	feature/backfill-score	main	fusionnée, 30e0c7e

Chaque cible est main. Chaque source, sauf une, part de main. L’exception est hotfix/1.2.1, qui part de l’étiquette v1.2.0. Sur GitHub, la page de demande de tirage l’indique en une ligne, comme sur la PR nº 3 : « a fusionné 1 commit dans main depuis feature/classifier-1.1 ».

La règle du projet, dans docs/release-process.md (la leçon 3 l’écrit) :

docs/release-process.md (Branches section)

| Branch | Made from | Merges into | Used for |
|---|---|---|---|
| `main` | | | The current code. Every commit on `main` is built once, and the image can go to production. |
| `feature/<short-name>` | `main` | `main`, by pull request | Every normal change. Short-lived: one change, merged within a few days. |
| `hotfix/<version>` | the release tag, for example `v1.2.0` | `main`, by pull request, after the release | An urgent fix to the version in production, when `main` already has changes that are not ready. |

Pratique guidée : lire vous-même l’historique

1. Clonez le dépôt de référence dans ~/projects/c19-reference, comme dans l’exemple détaillé.
2. Exécutez git branch --show-current. Vérifiez que la sortie est main.
3. Exécutez git log --oneline --first-parent main. Comptez les fusions de demandes de tirage.
4. Exécutez git log --oneline --graph --all. Trouvez le commit d’où part hotfix/1.2.1.
5. Exécutez git tag -n1. Notez chaque étiquette et son type de version (MAJOR, MINOR ou PATCH) par rapport à l’étiquette précédente.
6. Exécutez git tag --contains 7324d7b. Notez les versions qui contiennent la PR nº 3.
7. Exécutez git merge-base --is-ancestor fc9005a 6ae49dc && echo yes || echo no. Prédisez d’abord la réponse : le correctif était-il sur main à 6ae49dc?
8. Exécutez la même commande avec 3464f2c au lieu de 6ae49dc.

Afficher les résultats attendus

2. main.
3. Sept fusions de demandes de tirage : nº 1, nº 2, nº 3, nº 5, nº 6, nº 7 et nº 8. La PR nº 4 a été fermée.
4. hotfix/1.2.1 part de c3c7135, le commit avec l’étiquette v1.2.0. Dans le graphe, fc9005a (tag: v1.2.1) a c3c7135 comme parent.
5. v1.1.0, le début; v1.2.0, MINOR (nouveau champ score, les anciens clients fonctionnent encore); v1.2.1, PATCH (un correctif).
6. v1.2.0 et v1.2.1.
7. no (non). À 6ae49dc (PR nº 6), le correctif existait seulement sur la branche de correctif urgent. La production l’exécutait, mais main ne l’avait pas.
8. yes (oui). La PR nº 7 a fusionné le correctif dans main sous 3464f2c.

La commande git merge-base --is-ancestor A B demande : le commit A est-il dans l’historique du commit B? Elle n’affiche rien, et son code de sortie est 0 pour oui et 1 pour non. && echo yes || echo no affiche la réponse. Dans PowerShell, écrivez git merge-base --is-ancestor fc9005a 6ae49dc; if ($?) { "yes" } else { "no" }.

À vous de jouer : écrire la branche et la demande de tirage

Pour chaque changement, écrivez le nom de la branche, son point de départ et la demande de tirage sous la forme « source vers cible ». main contient déjà un changement qui n’est pas encore en production.

1. Sam signale que « J’ai perdu mon mot de passe » reçoit la priorité 1. L’équipe veut améliorer la règle pour « perdu », pour la prochaine mise en production normale.
2. La production utilise v1.2.1. Après un déploiement, le service de soutien constate que chaque billet reçoit la catégorie other (autre). L’équipe veut un correctif aujourd’hui.
3. Une faute d’orthographe dans README.md.

Afficher une réponse

1. feature/lost-password-rule, à partir de main. Demande de tirage : feature/lost-password-rule vers main. Elle sera livrée avec la prochaine mise en production depuis main. (La véritable demande de tirage no 4 a tenté cela, avec feature/fewer-urgent-tickets vers main. La barrière d’évaluation de l’IA l’a bloquée : leçon 3.)
2. hotfix/1.2.2, à partir de l’étiquette v1.2.1 (git switch -c hotfix/1.2.2 v1.2.1). Ajoutez l’étiquette v1.2.2 sur la branche après la réussite des vérifications, puis déployez cette image. Ensuite, ouvrez la demande de tirage hotfix/1.2.2 vers main, pour que la prochaine mise en production conserve le correctif. Elle ne part pas de main, car le changement sur main n’est pas prêt pour la production.
3. feature/readme-typo (ou docs/readme-typo si l’équipe utilise ce préfixe), à partir de main, vers main. C’est un changement normal. Il passe les mêmes vérifications que tous les autres changements, même s’il ne modifie aucun code.

Erreur courante

Le correctif est en production, mais pas sur main

Symptôme : un correctif urgent est en production et le bogue a disparu. Deux semaines plus tard, la prochaine mise en production depuis main ramène le même bogue. Les utilisateurs le voient de nouveau, et personne n’a modifié ce code.

Cause : la branche de correctif urgent partait de l’étiquette de mise en production. Son correctif se trouve donc seulement sur cette branche. main ne le reçoit pas automatiquement. Dans le dépôt de référence, c’était vrai pendant un court moment. Entre la mise en production de v1.2.1 (18 h 51) et la fusion de la demande de tirage no 7 (18 h 58), la production avait le correctif, mais pas main. Vérifiez-le dans votre clone :

Terminal

git merge-base --is-ancestor fc9005a 6ae49dc && echo yes || echo no

La sortie :

no

Le sens de la fusion est un deuxième piège. Le commit (enregistrement d’un changement) 543b003 Merge branch 'main' into hotfix/1.2.1 a fusionné main vers la branche de correctif urgent. Le bouton Update branch (mettre à jour la branche) de GitHub l’a fait, car les règles exigent une branche à jour. Cette fusion apporte les changements de main à la branche de correctif urgent. Elle n’apporte pas le correctif à main. Seule la demande de tirage no 7, hotfix/1.2.1 vers main, l’a fait.

Solution :

1. Ouvrez la demande de tirage « branche de correctif urgent vers main » dans l’heure de la mise en production. N’attendez pas la prochaine mise en production.
2. Lisez la source et la cible avant de fusionner : « hotfix/1.2.1 vers main ».
3. Vérifiez avec Git que le correctif se trouve sur main : git branch -a --contains <fix commit> doit afficher main.
4. Le correctif doit avoir un test qui échoue sans lui. Le test reste ensuite sur main et détecte le bogue s’il revient. Le module 5 montre le test de la version 1.2.1.

Pour un vrai service d’IA : un correctif de modèle peut se perdre de la même façon. Un correctif urgent définit un nouveau seuil ou une nouvelle règle. S’il n’est pas sur main, la prochaine mise en production du modèle ramène l’ancien comportement. Les utilisateurs constatent une régression, et les résultats d’évaluation du correctif urgent donnent un faux sentiment de sécurité.

Vérifiez votre compréhension

Prédisez : la version 2.0 supprime le champ désuet confidence. Quelle partie de la version change, et pourquoi pas le nombre du milieu?

Afficher la réponse

Le numéro MAJOR (majeur) : 1.2.1 → 2.0.0. Un client qui lit confidence (confiance) échoue après le changement. C’est donc un changement incompatible. Le nombre du milieu sert aux nouveautés que les anciens clients peuvent ignorer, comme l’ajout de score dans 1.2.0. C’est pourquoi 1.2.0 a conservé confidence et l’a seulement marqué comme désuet. Les clients ont ainsi le temps de passer à score avant 2.0.

Vérifiez votre compréhension

Pourquoi l'équipe utilise-t-elle le développement sur une branche principale pour l'API de billets? Pourquoi la branche de correctif urgent part-elle de l'étiquette v1.2.0 plutôt que de main?

Afficher la réponse

L’API de billets est un seul service avec un seul environnement de production. Les changements sont petits et déployés souvent, et les utilisateurs n’utilisent jamais une ancienne version. L’équipe n’a donc pas besoin d’une branche pour chaque version. main est toujours prête pour la mise en production : chaque changement a passé les vérifications, et le travail inachevé est désactivé. La branche de correctif urgent part de v1.2.0, car c’est exactement ce que la production utilise. Une branche issue de main apporterait aussi la demande de tirage no 6 en production. Celle-ci n’a pas encore été mise en production ni testée comme version à livrer. Après la mise en production, la demande de tirage hotfix/1.2.1 vers main ramène le correctif sur main.

Récapitulatif

• Un flux de branches indique où chaque changement commence et où il est fusionné. Une demande de tirage l’écrit sous la forme « source vers cible ».
• Développement sur une branche principale : une seule branche main durable, toujours prête pour la mise en production; des branches de fonctionnalité courtes; une mise en production correspond à une étiquette sur main. Branches de mise en production : une branche par version prise en charge; les correctifs y sont faits, puis fusionnés dans main.
• L’API de billets utilise le développement sur une branche principale : un seul service, de petits changements, de nombreux déploiements. Un paramètre désactive le travail inachevé.
• Une branche de correctif urgent part de l’étiquette de mise en production et revient dans main par une demande de tirage. Vérifiez-le avec git branch -a --contains <commit>.
• Gestion sémantique des versions : PATCH (correctif) pour un correctif, MINOR (mineur) pour une nouveauté que les anciens clients peuvent ignorer, MAJOR pour un changement incompatible. Une étiquette Git nomme un commit; une étiquette d’image nomme une image, et l’empreinte représente son contenu.
• Pour supprimer le clone d’exercice : supprimez le dossier ~/projects/c19-reference. Rien d’autre n’a changé.

Leçon suivante : Définir les vérifications