Branches de version et étiquettes

Ce que vous saurez faire

Donnez au service de soutien une version des notes qui reste fixe pendant que votre équipe continue de travailler. Après cette leçon, vous pourrez dire quelle référence contient le nouveau travail, la prochaine version et la version publiée.

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

Ce que vous devez savoir

• Comment fusionner une demande de tirage (pull request) et lire le commit (enregistrement des changements) de fusion dans git log --graph, expliqué dans Les étapes d’une demande de tirage : 8. Fusionner.
• Comment pousser une branche et définir sa branche de suivi, expliqué dans Synchroniser de façon réfléchie : Amira pousse ses commits.

Ce qu’il vous faut sur votre ordinateur

• Le dossier ~/projects/nextia-learning-labs. Vous l’avez cloné dans Les étapes d’une demande de tirage : préparer le laboratoire d’exercice. S’il manque, faites l’étape 2 de cette section.
• Git, avec votre nom et votre adresse courriel, configuré dans Configurer Git : Étape 2 : indiquer votre identité à Git. Git les inscrit dans chaque étiquette que vous créez.
• Cette leçon utilise un nouvel état d’exercice, appelé release. Vous le créez dans Préparer l’état d’exercice. La commande de préparation supprime votre ancien dossier c14-lab et le recrée. Vous n’avez pas besoin de votre travail du module 4.
• Les empreintes des commits créés par le script de préparation sont les mêmes que dans cette leçon. Les commits que vous créez vous-même ont des empreintes différentes.

L’équipe publie une version

L’équipe rédige les notes du service de soutien dans ticket-notes. Jusqu’ici, tout le travail allait dans main. Maintenant, le service de soutien veut une version fixe qu’il peut utiliser chaque jour. Il l’appelle version 1.0.

main ne peut pas être cette version. L’équipe fait des commits sur main chaque jour, donc main change chaque jour. Le service de soutien a besoin de notes qui changent seulement quand l’équipe décide de corriger quelque chose.

L’équipe utilise donc trois références. Une référence est un nom qui pointe vers un commit, par exemple un nom de branche.

Référence	Exemple	Ce qu’elle contient	Est-ce qu’elle bouge?
Développement	main	Le nouveau travail. Tous les changements terminés vont ici.	Oui, à chaque changement fusionné.
Version candidate	release/1.0	La prochaine version. L’équipe la teste.	Seulement pour des corrections.
Production	v1.0.0	La version utilisée par le service de soutien.	Jamais.

Une branche de version est une branche que vous créez à partir de main quand la prochaine version est prête. C’est la version candidate : celle que l’équipe teste avant de la remettre au service de soutien. Après sa création, elle accepte seulement des corrections. Le nouveau travail continue sur main et fera partie de la prochaine version.

Une étiquette est un nom fixe pour un commit. Une branche bouge quand vous faites un commit dessus. Une étiquette ne bouge jamais. Quand l’équipe publie la version 1.0, elle place l’étiquette v1.0.0 sur le commit de publication. La « production » désigne ce que les utilisateurs ont maintenant. L’étiquette marque donc la production.

Numéros de version

La plupart des équipes écrivent les versions avec trois nombres : MAJEURE.MINEURE.CORRECTIF.

Changement	Exemple	Quand
CORRECTIF	1.0.0 → 1.0.1	Une correction seulement. Rien de nouveau.
MINEURE	1.0.1 → 1.1.0	Du nouveau contenu qui ne change pas la façon d’utiliser les notes.
MAJEURE	1.1.0 → 2.0.0	Un changement que les gens doivent apprendre, par exemple une nouvelle organisation des fichiers.

Le v au début de v1.0.0 est une convention courante pour les noms d’étiquettes. La branche de version a seulement les deux premiers nombres, release/1.0, car toutes les corrections 1.0.x y vont.

Préparer l’état d’exercice

1. Allez dans votre dossier de projets et exécutez le script de préparation avec le scénario release :

   Terminal

   cd ~/projects
   sh nextia-learning-labs/C14/setup.sh release --reset

   Sortie

   Ready: /Users/amira/projects/c14-lab
     ticket-notes     your clone
     sam-notes        Sam's clone
     team-remote.git  the shared remote
   Next: cd c14-lab/ticket-notes
   To start this scenario again: sh nextia-learning-labs/C14/setup.sh release --reset

2. Allez dans votre clone et examinez l’historique :

   Terminal

   cd c14-lab/ticket-notes
   git log --oneline -3

   Sortie

   465d7ea (HEAD -> main, origin/main, origin/HEAD) Add escalation rules
   f330fdc Add ticket 104
   e058b3f Add ticket 103

   Si vos empreintes sont différentes, exécutez de nouveau la commande de préparation. Ne continuez pas avec des empreintes différentes.

Exemple détaillé : Amira publie la version 1.0

L’équipe convient que main, au commit 465d7ea, est prêt à devenir la version 1.0.

Créer la branche de version

Branche actuelle : main. Amira lance d’abord la vérification, car une version doit la réussir :

Terminal

sh check.sh

Sortie

PASS: 4 ticket lines checked

Elle crée la branche de version à partir de main et la pousse pour que l’équipe puisse la voir :

Terminal

git switch -c release/1.0
git push -u origin release/1.0

Sortie

Switched to a new branch 'release/1.0'
To /Users/amira/projects/c14-lab/team-remote.git
 * [new branch]      release/1.0 -> release/1.0
branch 'release/1.0' set up to track 'origin/release/1.0'.

Branche actuelle : maintenant release/1.0. Le / dans le nom fait simplement partie du nom. Les équipes utilisent release/ pour regrouper toutes les branches de version dans les listes.

Étiqueter la version

L’équipe a testé la version candidate et n’a trouvé aucun problème. Amira étiquette le commit comme version 1.0.0. L’option -a crée une étiquette annotée : elle conserve aussi son auteur, sa date de création et un message.

Terminal

git tag -a v1.0.0 -m "Help desk notes 1.0"
git tag

Sortie

v1.0.0

Sans nom, git tag liste toutes les étiquettes. Pour voir vers quoi pointe une étiquette, utilisez git show :

Terminal

git show v1.0.0

Sortie

tag v1.0.0
Tagger: Amira Khan <amira@example.com>
Date:   Mon Oct 5 22:03:44 2026 -0400

Help desk notes 1.0

commit 465d7ea589a41feac19db85754dd27d487d78f76
Author: Amira Khan <amira@example.com>
Date:   Tue Oct 6 09:09:00 2026 -0400

    Add escalation rules

diff --git a/escalation.txt b/escalation.txt
...

La première partie est l’étiquette : son auteur, sa date de création et le message. La deuxième partie est le commit vers lequel pointe l’étiquette, 465d7ea.

Remarque

Une étiquette sans -a est une étiquette légère. C’est seulement un nom, sans auteur, date ni message. Utilisez des étiquettes annotées pour les versions. L’équipe peut ainsi voir qui a publié chaque version et quand.

Pousser l’étiquette

git push n’envoie pas les étiquettes. Amira le vérifie :

Terminal

git push

Sortie

Everything up-to-date

L’étiquette se trouve encore seulement dans son dépôt. Elle la pousse par son nom :

Terminal

git push origin v1.0.0

Sortie

To /Users/amira/projects/c14-lab/team-remote.git
 * [new tag]         v1.0.0 -> v1.0.0

Sam peut maintenant la récupérer. Dans sam-notes, une récupération montre la nouvelle branche et la nouvelle étiquette :

Terminal (Sam)

git fetch
git tag

Sortie

From /Users/amira/projects/c14-lab/team-remote
 * [new branch]      release/1.0 -> origin/release/1.0
 * [new tag]         v1.0.0      -> v1.0.0
v1.0.0

Remarque

git push --follow-tags pousse la branche actuelle ainsi que ses étiquettes annotées. Certaines équipes en font leur réglage par défaut. Dans ce cours, poussez chaque étiquette par son nom pour toujours savoir ce que vous avez envoyé.

main continue, la version ne bouge pas

Branche actuelle : main. Amira y revient avec git switch main. Elle commence une nouvelle fonctionnalité : l’exportation des billets. Elle crée export.txt :

export.txt

Export format: one CSV row for each ticket.
TODO: decide the columns.

L’exportation n’est pas terminée, mais elle fait un commit et pousse son travail sur main :

Terminal

git add export.txt
git commit -m "Start the ticket export (not finished)"
git push

Sortie (fin)

[main eaa41a2] Start the ticket export (not finished)
 1 file changed, 2 insertions(+)
 create mode 100644 export.txt
To /Users/amira/projects/c14-lab/team-remote.git
   465d7ea..eaa41a2  main -> main

Elle examine maintenant toutes les références. --decorate affiche les noms des branches et des étiquettes à côté des commits :

Terminal

git log --oneline --graph --all --decorate

Sortie (premières lignes)

* eaa41a2 (HEAD -> main, origin/main, origin/HEAD) Start the ticket export (not finished)
* 465d7ea (tag: v1.0.0, origin/release/1.0, release/1.0) Add escalation rules
* f330fdc Add ticket 104

Lisez à partir du haut :

• main a avancé jusqu’à eaa41a2. Le développement continue.
• release/1.0 est restée sur 465d7ea. L’exportation inachevée ne fait pas partie de la version candidate.
• v1.0.0 est restée sur 465d7ea. Le service de soutien a encore exactement la version 1.0.

La branche de version peut encore bouger. Si le service de soutien trouve un bogue dans la version 1.0, une correction va sur release/1.0. L’équipe crée ensuite l’étiquette v1.0.1. La prochaine leçon montre comment faire. L’étiquette v1.0.0 ne bouge jamais. Elle désigne toujours la première version reçue par le service de soutien.

Exercice guidé : publier la version 1.0

1. Exécutez la commande de préparation de Préparer l’état d’exercice, puis allez dans c14-lab/ticket-notes.

2. Exécutez git status. La sortie doit inclure On branch main (sur la branche main) et working tree clean (arbre de travail propre).

3. Exécutez sh check.sh. La sortie doit commencer par PASS (réussite).

4. Créez la branche de version et poussez-la :

   Terminal

   git switch -c release/1.0
   git push -u origin release/1.0

   Branche actuelle : maintenant release/1.0. La sortie inclut * [new branch] release/1.0 -> release/1.0 (nouvelle branche).

5. Étiquetez la version :

   Terminal

   git tag -a v1.0.0 -m "Help desk notes 1.0"

6. Exécutez git show v1.0.0. Vérifiez que la ligne du commit affiche 465d7ea.

7. Poussez l’étiquette :

   Terminal

   git push origin v1.0.0

   La sortie inclut * [new tag] v1.0.0 -> v1.0.0 (nouvelle étiquette).

8. Passez à main :

   Terminal

   git switch main

9. Dans votre éditeur, créez export.txt avec les deux lignes de l’exemple détaillé. Enregistrez-le.

10. Faites un commit et poussez-le sur main :

    Terminal

    git add export.txt
    git commit -m "Start the ticket export (not finished)"
    git push

11. Exécutez git log --oneline --graph --all --decorate. Vérifiez trois choses :

    • main pointe vers votre nouveau commit.
    • release/1.0 pointe vers 465d7ea.
    • tag: v1.0.0 (étiquette : v1.0.0) pointe vers 465d7ea.

12. Allez dans le clone de Sam et vérifiez qu’il peut voir l’étiquette :

    Terminal

    cd ../sam-notes
    git fetch
    git tag

    La sortie se termine par v1.0.0. Revenez ensuite avec cd ../ticket-notes.

À vous de jouer : publier la version 1.1

L’exportation est maintenant terminée. L’équipe veut la publier comme version 1.1.

1. Sur main, complétez export.txt. Par exemple, remplacez la ligne TODO (à faire) par Columns: number, summary, action. (colonnes : numéro, résumé, action). Créez un commit (enregistrement des modifications) et poussez-le.
2. Créez la version candidate 1.1, ajoutez l’étiquette de la version publiée 1.1.0, puis poussez la branche et l’étiquette. Choisissez vous-même les noms selon les règles de cette leçon.
3. Prouvez trois choses avec des commandes :
   • release/1.0 et v1.0.0 n’ont pas bougé.
   • La version 1.0.0 ne contient pas export.txt.
   • La version 1.1.0 contient export.txt.

Afficher une réponse modèle

Les noms sont release/1.1 (une nouvelle version MINOR, avec du nouveau contenu) et v1.1.0.

Terminal

git switch main
git commit -am "Finish the ticket export"
git push
git switch -c release/1.1
git tag -a v1.1.0 -m "Help desk notes 1.1"
git push -u origin release/1.1
git push origin v1.1.0
git log --oneline --graph --all --decorate -5

Output (git log only)

* 5cddf4e (HEAD -> release/1.1, tag: v1.1.0, origin/release/1.1, origin/main, origin/HEAD, main) Finish the ticket export
* eaa41a2 Start the ticket export (not finished)
* 465d7ea (tag: v1.0.0, origin/release/1.0, release/1.0) Add escalation rules
* f330fdc Add ticket 104
* e058b3f Add ticket 103

release/1.0 et v1.0.0 pointent toujours vers 465d7ea. Pour voir les fichiers de chaque version, affichez la liste des fichiers associés à l’étiquette :

Terminal

git ls-tree --name-only v1.0.0

Sortie

.gitignore
README.md
check.sh
contacts.txt
escalation.txt
tickets.txt

export.txt ne figure pas dans la liste. La même commande avec v1.1.0 affiche aussi export.txt.

Vos valeurs de hachage pour 5cddf4e et eaa41a2 sont différentes, car vous avez créé ces commits vous-même.

Remarque

Certaines équipes ajoutent aussi une étiquette à la version candidate avant la publication, par exemple v1.1.0-rc.1 pour « version candidate 1 ». Si les tests révèlent un problème, elles le corrigent sur la branche de publication et ajoutent l’étiquette v1.1.0-rc.2. Quand une version candidate réussit les tests, elles ajoutent l’étiquette v1.1.0 au même commit. Ce cours ne nécessite pas d’étiquettes de version candidate.

Erreur courante

J'ai créé l'étiquette, mais Sam ne la voit pas

Symptôme : vous avez créé v1.0.0 et exécuté git push. Sam exécute git fetch, puis git tag, et ne voit rien :

Output (Sam)

From /Users/amira/projects/c14-lab/team-remote
 * [new branch]      release/1.0 -> origin/release/1.0

Cause : git push envoie les branches, pas les étiquettes. L’étiquette existe seulement dans votre dépôt.

Solution :

1. Vérifiez quelles étiquettes se trouvent dans le dépôt distant :

   Terminal

   git ls-remote --tags origin

   Si la sortie est vide, le dépôt distant n’a aucune étiquette.

2. Poussez l’étiquette en précisant son nom : git push origin v1.0.0.

3. Demandez à Sam d’exécuter git fetch de nouveau. La sortie affiche * [new tag] (nouvelle étiquette).

Après l’envoi, git ls-remote --tags origin affiche deux lignes pour l’étiquette. La ligne qui se termine par ^{} indique le commit :

Sortie

2131d28c763e2fbb027721bef294f9f7bf1e405b  refs/tags/v1.0.0
465d7ea589a41feac19db85754dd27d487d78f76  refs/tags/v1.0.0^{}

Erreur courante

J'ai ajouté l'étiquette au mauvais commit

Symptôme : vous vouliez ajouter une étiquette à la version publiée, mais vous étiez sur main. git log --oneline --decorate -2 montre l’étiquette sur le travail inachevé :

Sortie

eaa41a2 (HEAD -> main, tag: v1.0.1, origin/main, origin/HEAD) Start the ticket export (not finished)
465d7ea (tag: v1.0.0, origin/release/1.0, release/1.0) Add escalation rules

Cause : git tag ajoute une étiquette au commit vers lequel HEAD pointe, sauf si vous précisez un commit. Vous étiez sur la mauvaise branche.

Attention

Lisez ceci avant de supprimer une étiquette. Si vous avez déjà poussé l’étiquette, ne la supprimez pas et ne la déplacez pas. D’autres personnes et outils l’utilisent peut-être déjà. Déplacer une étiquette déjà poussée revient à réécrire l’historique partagé. Avisez votre équipe et publiez une nouvelle version avec le numéro suivant.

Solution : si vous n’avez pas poussé l’étiquette, supprimez-la et ajoutez une étiquette au bon commit :

1. Supprimez l’étiquette locale :

   Terminal

   git tag -d v1.0.1

   Sortie

   Deleted tag 'v1.0.1' (was edbb130)

   edbb130 est l’étiquette elle-même, pas un commit.

2. Passez à la bonne branche, par exemple avec git switch release/1.0.

3. Créez de nouveau l’étiquette avec git tag -a.

Si vous tentez de créer une étiquette avec un nom existant, Git refuse. Par exemple, git tag -a v1.0.0 -m "x" affiche fatal: tag 'v1.0.0' already exists (erreur fatale : l’étiquette « v1.0.0 » existe déjà).

Vérifiez votre compréhension

Faites une prédiction : Sam fusionne trois autres demandes de tirage dans main. Parmi main, release/1.0 et v1.0.0, lesquels bougent?

Afficher la réponse

Seule main bouge. Les demandes de tirage (pull requests) ciblent main, donc seule main reçoit les nouveaux commits. release/1.0 bouge seulement quand quelqu’un y fusionne une correction. v1.0.0 ne bouge jamais, donc le service d’assistance conserve exactement la version 1.0.

Vérifiez votre compréhension

Vérification pratique : montrez vers quel commit chaque référence pointe et prouvez que l'étiquette se trouve dans le dépôt distant.

Afficher la réponse

Exécutez git log --oneline --graph --all --decorate. Chaque commit affiche les noms de ses branches et étiquettes, par exemple (tag: v1.0.0, origin/release/1.0, release/1.0). Ensuite, exécutez git ls-remote --tags origin. Si la sortie contient refs/tags/v1.0.0, le dépôt distant contient l’étiquette.

Récapitulatif

• main sert au développement. Elle bouge à chaque modification fusionnée.
• Une branche de publication, par exemple release/1.0, représente la version candidate. Vous la créez à partir de main, et elle accepte seulement les corrections.
• Une étiquette, par exemple v1.0.0, marque la version publiée. Elle ne bouge jamais. Utilisez git tag -a pour les versions publiées.
• git push n’envoie pas les étiquettes. Poussez chaque étiquette avec git push origin <tag>.
• Les versions utilisent MAJOR.MINOR.PATCH. Une correction change seulement le numéro PATCH.

Leçon suivante : Appliquer un correctif avec cherry-pick