Garder des historiques cohérents

Ce que vous saurez faire

Assurez-vous qu’un correctif d’une version se retrouve aussi dans la prochaine version. Après cette leçon, vous pourrez repérer les correctifs de version absents de main et les y ramener. Vous pourrez aussi repérer un correctif présent deux fois dans l’historique.

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

Ce que vous devez savoir

• La séquence de correction urgente et git cherry-pick -x, dans Appliquer un correctif avec cherry-pick : la séquence du correctif urgent.
• Comment résoudre un conflit de fusion, dans Les conflits, étape par étape : résoudre, tester et créer un commit.

Ce qu’il vous faut sur votre ordinateur

• ~/projects/c14-lab/ticket-notes dans l’état à la fin de Appliquer un correctif avec cherry-pick : exercice guidé : publier la version 1.0.1 : sur release/1.0, avec l’étiquette v1.0.1 poussée.
• Si vous avez aussi fait l’exercice « À vous de jouer », ou en cas de doute, utilisez les commandes de Obtenir l’état de départ. Elles recréent l’état hotfix (correction urgente) et répètent la correction urgente.

Obtenir l’état de départ

Ces commandes recréent l’état de l’exercice et répètent la correction urgente de la leçon précédente. Exécutez-les une à la fois, depuis ~/projects :

Terminal

sh nextia-learning-labs/C14/setup.sh hotfix --reset
cd c14-lab/ticket-notes
git switch release/1.0
git switch -c hotfix/1.0.1
git cherry-pick -x aeeb4b6
git push -u origin hotfix/1.0.1
git switch release/1.0
git merge --no-ff --no-edit hotfix/1.0.1
git tag -a v1.0.1 -m "Help desk notes 1.0.1"
git push
git push origin v1.0.1

Vérifiez ensuite l’état :

Terminal

git status

Sortie

On branch release/1.0
Your branch is up to date with 'origin/release/1.0'.

nothing to commit, working tree clean

Deux endroits, un correctif

Un correctif peut commencer à deux endroits :

• D’abord sur main. Sam a corrigé le numéro de poste de l’équipe réseau sur main. Amira l’a ensuite copié dans la version avec cherry-pick (copie d’un commit). main contient déjà le correctif.
• D’abord sur la version. Parfois, le bogue est urgent, ou le code de main a trop changé. L’équipe corrige alors directement la version, avec une branche de correction urgente créée à partir de release/1.0. Maintenant, main ne contient pas le correctif.

Le deuxième cas présente un risque. La prochaine version, 1.1, part de main. Si main ne contient pas le correctif, la version 1.1 retrouve l’ancien bogue. Une régression est un bogue corrigé qui revient ensuite.

Pour l’éviter, vous ramenez le correctif dans main. La méthode habituelle est une fusion de retour : vous fusionnez la branche de version dans main. Vous utilisez une demande de tirage (pull request) de release/1.0 vers main. « Retour » signifie un retour au développement. Vous pouvez aussi copier le correctif dans main avec cherry-pick. Mais une fusion ramène tous les correctifs de version à la fois, sans en oublier.

Les correctifs passent de main à la version avec cherry-pick. Les correctifs de version reviennent dans main avec une fusion.

Les équipes parlent aussi de fusion vers l’avant. Il s’agit d’une fusion d’une ancienne branche de version dans une plus récente, par exemple de release/1.0 vers release/1.1. Elle transmet un correctif dans l’ordre des versions. Les équipes utilisent ces noms de différentes façons. Quand vous rejoignez une équipe, demandez quelle direction chaque nom désigne.

Exemple détaillé : un correctif d’abord sur la version

1. Faire la vérification avant la prochaine version

Branche actuelle : release/1.0. Avant de créer une nouvelle branche de version, l’équipe liste les commits de la version absents de main :

Terminal

git log --oneline main..release/1.0

Sortie

257b55a Merge branch 'hotfix/1.0.1' into release/1.0
19b64c1 Fix the network team extension

19b64c1 est la copie du correctif de Sam. main contient le même changement, dans aeeb4b6, mais Git compare les commits, pas les changements. La copie est un commit (enregistrement de changements) différent, donc Git l’affiche.

Pour comparer les changements, utilisez trois points et --cherry-mark. main...release/1.0 liste les commits présents d’un côté ou de l’autre, mais pas des deux. --left-right marque chacun avec < pour main ou > pour release/1.0. --cherry-mark affiche = quand l’autre côté contient un commit avec le même changement :

Terminal

git log --oneline --left-right --cherry-mark main...release/1.0

Sortie

> 257b55a Merge branch 'hotfix/1.0.1' into release/1.0
= 19b64c1 Fix the network team extension
< 3f4d833 Add ticket 105
= aeeb4b6 Fix the network team extension
< 3cf73f7 Start the ticket export (not finished)

Les marques = montrent que aeeb4b6 et 19b64c1 contiennent le même changement. Le même correctif apparaît deux fois dans l’historique : c’est un correctif en double. C’est normal après un cherry-pick. La ligne -x dans 19b64c1 indique aussi aeeb4b6, ce qui permet de voir le lien.

2. Corriger directement la version

Le centre d’assistance signale que « plus de 2 jours » n’est pas clair. Il faut écrire « 2 jours ouvrables ». Le correctif est urgent, donc Amira corrige d’abord la version.

Branche actuelle : release/1.0. Elle crée une branche de correction urgente à partir de celle-ci :

Terminal

git switch -c hotfix/1.0.2

Branche actuelle : hotfix/1.0.2. Elle modifie la dernière ligne de escalation.txt dans son éditeur, puis vérifie les différences :

git diff

diff --git a/escalation.txt b/escalation.txt
index 12f9ff4..1b5f8a3 100644
--- a/escalation.txt
+++ b/escalation.txt
@@ -1,3 +1,3 @@
 Escalate a ticket when:
 - the user cannot work, or
-- the ticket is open for more than 2 days.
+- the ticket is open for more than 2 working days.

Elle fait un commit, vérifie et pousse :

Terminal

git commit -am "Fix the escalation wording"
sh check.sh
git push -u origin hotfix/1.0.2

Sortie

[hotfix/1.0.2 c27858d] Fix the escalation wording
 1 file changed, 1 insertion(+), 1 deletion(-)
PASS: 4 ticket lines checked
To /Users/amira/projects/c14-lab/team-remote.git
 * [new branch]      hotfix/1.0.2 -> hotfix/1.0.2
branch 'hotfix/1.0.2' set up to track 'origin/hotfix/1.0.2'.

Demande de tirage : source hotfix/1.0.2 → cible release/1.0. Sam la révise et l’approuve.

Branche actuelle : release/1.0. Amira passe à la cible, puis fusionne, crée une étiquette et pousse :

Terminal

git switch release/1.0
git merge --no-ff --no-edit hotfix/1.0.2
git tag -a v1.0.2 -m "Help desk notes 1.0.2"
git push
git push origin v1.0.2

Sortie (fin)

To /Users/amira/projects/c14-lab/team-remote.git
   257b55a..03ee8af  release/1.0 -> release/1.0
To /Users/amira/projects/c14-lab/team-remote.git
 * [new tag]         v1.0.2 -> v1.0.2

Le centre d’assistance a le correctif. Mais main ne l’a pas :

Terminal

git show main:escalation.txt

Sortie

Escalate a ticket when:
- the user cannot work, or
- the ticket is open for more than 2 days.

Si l’équipe crée maintenant release/1.1 à partir de main, la version 1.1 indique de nouveau « 2 jours ». C’est une régression.

3. Fusionner la version dans main

Demande de tirage : source release/1.0 → cible main. La personne responsable de la révision examine ce que la demande apporte à main :

Terminal

git diff main...release/1.0 --stat

Sortie

 contacts.txt   | 2 +-
 escalation.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

La demande de tirage montre les deux correctifs de version. Ce sont deux correctifs, sans travail inachevé. La personne responsable de la révision l’approuve donc.

Branche actuelle : main. Amira passe à la cible de la demande de tirage. Elle récupère d’abord les changements pour fusionner dans la version la plus récente de main :

Terminal

git switch main
git pull
git merge --no-ff --no-edit release/1.0

Sortie (fin)

Already up to date.
Merge made by the 'ort' strategy.
 escalation.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Regardez le résultat. La demande de tirage montrait deux fichiers, mais la fusion a modifié seulement escalation.txt. main contenait déjà le changement de l’équipe réseau provenant de aeeb4b6. Git a reconnu le même changement des deux côtés et a gardé une seule copie de la ligne, sans conflit.

Branche actuelle : main. Elle lance la vérification et pousse :

Terminal

sh check.sh
git push

Sortie

PASS: 5 ticket lines checked
To /Users/amira/projects/c14-lab/team-remote.git
   3f4d833..9c54d1b  main -> main

4. Lire le nouvel historique

Terminal

git log --oneline --graph --decorate -9

Sortie

*   9c54d1b (HEAD -> main, origin/main, origin/HEAD) Merge branch 'release/1.0'
|\
| *   03ee8af (tag: v1.0.2, origin/release/1.0, release/1.0) Merge branch 'hotfix/1.0.2' into release/1.0
| |\
| | * c27858d (origin/hotfix/1.0.2, hotfix/1.0.2) Fix the escalation wording
| |/
| *   257b55a (tag: v1.0.1) Merge branch 'hotfix/1.0.1' into release/1.0
| |\
| | * 19b64c1 (origin/hotfix/1.0.1, hotfix/1.0.1) Fix the network team extension
| |/
* | 3f4d833 Add ticket 105
* | aeeb4b6 Fix the network team extension
* | 3cf73f7 Start the ticket export (not finished)
|/
* 465d7ea (tag: v1.0.0) Add escalation rules

La vérification de l’étape 1 ne donne maintenant aucun résultat. main contient tous les commits de la version, donc cette commande n’affiche rien :

Terminal

git log --oneline main..release/1.0

Le doublon est toujours là. main contient maintenant deux commits avec le même changement :

Terminal

git log --oneline --grep "network team" main

Sortie

19b64c1 Fix the network team extension
aeeb4b6 Fix the network team extension

--grep liste seulement les commits dont le message contient le texte. Ici, le doublon est sans conséquence : les deux commits font le même changement, donc le fichier est correct.

Quand les correctifs en double causent des problèmes

Deux copies du même changement fusionnent sans problème. Deux correctifs différents pour le même bogue ne le font pas. Par exemple, Amira écrit « 2 jours ouvrables » sur la version, et Sam écrit « 48 heures » sur main. Il se produit alors l’une de ces deux situations :

• Les deux correctifs modifient la même ligne. La fusion de retour s’arrête sur un conflit. La première erreur courante ci-dessous le montre.
• Les correctifs modifient des lignes différentes. Git les fusionne sans conflit, et le fichier contient maintenant les deux correctifs. Par exemple, un contact manquant est ajouté deux fois, à deux endroits.

Pour éviter cela, utilisez un seul correctif provenant d’une seule source :

• Convenez d’une règle d’équipe et utilisez une seule de ces méthodes :
  • Corriger d’abord sur main, puis copier dans la version avec cherry-pick (la leçon précédente).
  • Corriger d’abord sur la version, puis fusionner la version dans main (cette leçon).
• Avant d’écrire un correctif, vérifiez si quelqu’un a déjà corrigé le bogue, par exemple avec git log --oneline --grep "escalation" --all.
• Utilisez toujours cherry-pick -x, pour que chaque copie indique son original.
• Fusionnez la version dans main après chaque publication, pas plusieurs semaines plus tard.

Exercice guidé : corriger la version, puis la fusionner dans main

1. Commencez par Obtenir l’état de départ. Branche actuelle : release/1.0.

2. Exécutez git log --oneline --left-right --cherry-mark main...release/1.0. Deux lignes commencent par =.

3. Créez la branche de correction urgente à partir de la version :

   Terminal

   git switch -c hotfix/1.0.2

   Branche actuelle : hotfix/1.0.2.

4. Dans escalation.txt, remplacez more than 2 days (plus de 2 jours) par more than 2 working days (plus de 2 jours ouvrables). Enregistrez le fichier.

5. Faites un commit, vérifiez et poussez :

   Terminal

   git commit -am "Fix the escalation wording"
   sh check.sh
   git push -u origin hotfix/1.0.2

6. Révisez la demande de tirage, source hotfix/1.0.2 → cible release/1.0, avec git diff release/1.0...hotfix/1.0.2. Les différences touchent seulement escalation.txt.

7. Fusionnez-la dans la cible et publiez v1.0.2 :

   Terminal

   git switch release/1.0
   git merge --no-ff --no-edit hotfix/1.0.2
   git tag -a v1.0.2 -m "Help desk notes 1.0.2"
   git push
   git push origin v1.0.2

   Branche actuelle : release/1.0.

8. Exécutez git show main:escalation.txt. Le fichier indique encore 2 days (2 jours).

9. Exécutez git log --oneline main..release/1.0. La sortie liste quatre commits, dont Fix the escalation wording (corriger la formulation de l’escalade).

10. Révisez la demande de tirage de fusion de retour, source release/1.0 → cible main :

    Terminal

    git diff main...release/1.0 --stat

    La sortie liste contacts.txt et escalation.txt, et rien d’autre.

11. Passez à main et récupérez les changements :

    Terminal

    git switch main
    git pull

    Branche actuelle : main.

12. Fusionnez la version dans main :

    Terminal

    git merge --no-ff --no-edit release/1.0

    La sortie liste seulement escalation.txt.

13. Exécutez sh check.sh. La sortie commence par PASS (réussite). Exécutez ensuite git push.

14. Exécutez git log --oneline main..release/1.0. La sortie est vide.

15. Exécutez git log --oneline --grep "network team" main. La sortie liste deux commits avec le même message.

À vous de jouer : reporter une correction avec cherry-pick

Le numéro de poste du service d’assistance est incorrect dans la version publiée. Il doit être 4110, pas 4100. Partez de la fin de l’exercice guidé.

1. Publiez la correction dans v1.0.3. Faites-la d’abord sur la branche de version, avec une branche de correctif urgent.
2. Reportez la correction sur main avec un cherry-pick (copie d’un commit), pas une fusion de retour. Utilisez une branche appelée port-help-desk-fix, créée à partir de main, et une demande de tirage qui cible main.
3. Exécutez git log --oneline main..release/1.0. La sortie est-elle vide? Expliquez pourquoi et montrez une commande qui prouve que main contient la correction.

Notez la branche courante, ainsi que la source et la cible de la demande de tirage à chaque étape.

Afficher une réponse modèle

Étape	Branche courante	Source → cible de la demande de tirage
Créer la branche de correctif urgent	release/1.0 → hotfix/1.0.3	aucune
Corriger, créer un commit (enregistrement des modifications), vérifier, pousser	hotfix/1.0.3	aucune
Réviser	hotfix/1.0.3	hotfix/1.0.3 → release/1.0
Fusionner, créer l’étiquette v1.0.3, pousser	release/1.0	hotfix/1.0.3 → release/1.0 (fusionnée)
Créer la branche de report	main → port-help-desk-fix	aucune
Faire le cherry-pick, vérifier, pousser	port-help-desk-fix	aucune
Réviser	port-help-desk-fix	port-help-desk-fix → main
Fusionner, pousser	main	port-help-desk-fix → main (fusionnée)

Terminal

git switch release/1.0
git switch -c hotfix/1.0.3
git commit -am "Fix the help desk extension"
sh check.sh
git push -u origin hotfix/1.0.3
git switch release/1.0
git merge --no-ff --no-edit hotfix/1.0.3
git tag -a v1.0.3 -m "Help desk notes 1.0.3"
git push
git push origin v1.0.3
git switch main
git switch -c port-help-desk-fix
git cherry-pick -x hotfix/1.0.3
sh check.sh
git push -u origin port-help-desk-fix
git switch main
git merge --no-ff --no-edit port-help-desk-fix
git push

Avant le commit, remplacez Help desk: ext. 4100 (service d’assistance : poste 4100) par Help desk: ext. 4110 (service d’assistance : poste 4110) dans contacts.txt. git cherry-pick -x hotfix/1.0.3 copie le dernier commit de hotfix/1.0.3, qui contient la correction.

Le résultat de la vérification n’est pas vide :

Terminal

git log --oneline main..release/1.0

Sortie

2810d0a Merge branch 'hotfix/1.0.3' into release/1.0
642f5ce Fix the help desk extension

main contient une copie de 642f5ce, pas 642f5ce lui-même. Git l’affiche donc dans la liste. --cherry-mark prouve que la modification existe des deux côtés :

Terminal

git log --oneline --left-right --cherry-mark main...release/1.0

Sortie (premières lignes)

< 211a8eb Merge branch 'port-help-desk-fix'
= 147f70e Fix the help desk extension
> 2810d0a Merge branch 'hotfix/1.0.3' into release/1.0
= 642f5ce Fix the help desk extension

git show main:contacts.txt affiche aussi Help desk: ext. 4110.

C’est une raison de préférer une fusion de retour. Après une fusion, le résultat de la vérification est vide quand tout se trouve sur main. Après un cherry-pick, la vérification liste des commits dont main contient déjà les modifications. Vous devez vérifier chacun avec --cherry-mark.

Erreur courante

Le bogue est revenu dans la version 1.1

Symptôme : l’équipe a terminé l’exportation et créé release/1.1 à partir de main. Le service d’assistance signale que la version 1.1 indique de nouveau « 2 jours » :

Terminal

git show release/1.1:escalation.txt

Sortie

Escalate a ticket when:
- the user cannot work, or
- the ticket is open for more than 2 days.

Cause : la correction a d’abord été faite sur release/1.0, et personne ne l’a fusionnée dans main. release/1.1 provient de main, donc elle ne contient pas la correction. La vérification montre les commits manquants. Les empreintes diffèrent de celles de l’exemple détaillé, car cette sortie provient d’un exercice distinct.

Terminal

git log --oneline release/1.1..release/1.0

Sortie

89962f3 Merge branch 'hotfix/1.0.2' into release/1.0
cafc5f2 Fix the escalation wording
e9e566e Merge branch 'hotfix/1.0.1' into release/1.0
4ef81fb Fix the network team extension

Correction :

1. Fusionnez l’ancienne branche de version dans la nouvelle, avec une demande de tirage de release/1.0 vers release/1.1. C’est une fusion vers l’avant. Branche courante : release/1.1.

   Terminal

   git merge --no-ff --no-edit release/1.0

   Sortie

   Merge made by the 'ort' strategy.
    escalation.txt | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

2. Exécutez de nouveau git log --oneline release/1.1..release/1.0. La sortie est vide.

3. Fusionnez aussi release/1.0 dans main, comme dans l’exemple détaillé. Sinon, release/1.2 aura le même problème.

Pour éviter cela, exécutez git log --oneline main..release/1.0 avant de créer une nouvelle branche de version. Faites une fusion de retour jusqu’à ce que la sortie soit vide ou que --cherry-mark affiche = pour chaque commit.

Erreur courante

La fusion de retour s'arrête sur un conflit

Symptôme : Amira a publié « 2 jours ouvrables » dans v1.0.2. En même temps, Sam a corrigé le même bogue sur main avec « 48 heures ». La fusion de retour dans main s’arrête :

Sortie

Auto-merging escalation.txt
CONFLICT (content): Merge conflict in escalation.txt
Automatic merge failed; fix conflicts and then commit the result.

Cause : deux personnes ont corrigé le même bogue de façons différentes. Les deux corrections modifient la même ligne, donc Git ne peut pas choisir. git diff montre les deux versions et l’original :

Sortie (fin)

  Escalate a ticket when:
  - the user cannot work, or
++<<<<<<< HEAD
 +- the ticket is open for more than 48 hours.
++||||||| 465d7ea
++- the ticket is open for more than 2 days.
++=======
 - the ticket is open for more than 2 working days.
++>>>>>>> release/1.0

Correction :

1. Parlez à Sam. Entendez-vous sur une formulation. Ici, l’équipe garde « 2 jours ouvrables », car le service d’assistance l’utilise déjà dans v1.0.2.

2. Modifiez escalation.txt pour qu’il contienne seulement la ligne convenue, sans marqueurs de conflit.

3. Ajoutez le fichier à la zone de préparation et terminez la fusion :

   Terminal

   git add escalation.txt
   git commit --no-edit

   Sortie

   [main f2744e8] Merge branch 'release/1.0'

4. Exécutez sh check.sh, puis git push.

Pour éviter cela, convenez d’une seule source pour chaque correction, comme dans Quand les correctifs en double causent des problèmes.

Vérification du module : la correction est au bon endroit

Le module vous demande de montrer deux choses : les deux branches contiennent la correction, et le travail sans rapport n’a pas été publié. Exécutez ces commandes à la fin de l’exercice guidé. Si vous avez aussi fait « À vous de jouer », la ligne du service d’assistance affiche ext. 4110 (poste 4110).

Les deux branches contiennent la ligne corrigée. Affichez le fichier sur chaque branche :

Terminal

git show release/1.0:contacts.txt
git show main:contacts.txt

Sortie

Help desk: ext. 4100
Network team: ext. 4401
Accounts team: ext. 4300
Help desk: ext. 4100
Network team: ext. 4401
Accounts team: ext. 4300

Les deux branches contiennent un commit avec la correction. --grep trouve les commits à partir de leur message :

Terminal

git log --oneline --grep "network team" release/1.0

Sortie

19b64c1 Fix the network team extension

Vous connaissez peut-être git branch --contains, qui liste les branches contenant un commit. Cette commande ne fonctionne pas pour une correction copiée par cherry-pick :

Terminal

git branch --contains aeeb4b6

Sortie

* main

release/1.0 n’est pas dans la liste, mais elle contient la correction. Elle contient la copie, 19b64c1, pas aeeb4b6. git branch --contains cherche un commit précis, pas une modification. Vérifiez donc le contenu du fichier, ou utilisez --grep et --cherry-mark.

Le travail sans rapport n’a pas été publié. Comparez la première version à l’état actuel de la branche de version :

Terminal

git diff v1.0.0 release/1.0 --stat

Sortie

 contacts.txt   | 2 +-
 escalation.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Seuls les deux fichiers corrigés ont changé. export.txt et tickets.txt ne sont pas dans la liste. L’exportation inachevée et le billet 105 n’ont donc pas été publiés.

Vérifiez votre compréhension

Prédisez : Amira corrige un bogue directement sur release/1.0 et publie v1.0.4. Personne ne fait de fusion de retour. Deux semaines plus tard, l'équipe crée release/1.1 à partir de main. La version 1.1 contient-elle la correction? Quelle commande montre le problème avant que l'équipe crée release/1.1?

Afficher la réponse

Non. release/1.1 provient de main, et main n’a jamais reçu la correction. Le bogue revient donc : c’est une régression. Exécutez git log --oneline main..release/1.0 avant de créer release/1.1. La commande liste le commit de correction, car main ne le contient pas. Fusionnez d’abord release/1.0 dans main, avec une demande de tirage de release/1.0 vers main.

Vérifiez votre compréhension

Vérification pratique : montrez que main et release/1.0 contiennent toutes deux la correction de l'équipe réseau et que l'exportation n'a pas été publiée. Pourquoi git branch --contains aeeb4b6 ne liste-t-elle pas release/1.0?

Afficher la réponse

• git show main:contacts.txt et git show release/1.0:contacts.txt affichent toutes deux Network team: ext. 4401 (équipe réseau : poste 4401).
• git log --oneline --grep "network team" release/1.0 liste 19b64c1, la copie avec la ligne -x.
• git diff v1.0.0 release/1.0 --stat liste seulement contacts.txt et escalation.txt. git show release/1.0:export.txt échoue.

git branch --contains cherche le commit précis aeeb4b6. La branche de version contient une copie avec une empreinte différente. La commande ne la liste donc pas, même si la modification s’y trouve.

Récapitulatif

• Une correction qui commence sur la branche de version doit aussi atteindre main. Sinon, la prochaine version ramène le bogue : c’est une régression.
• Une fusion de retour intègre la branche de version dans main, avec une demande de tirage de release/1.0 vers main. Une fusion vers l’avant va d’une ancienne branche de version vers une plus récente. Les noms varient selon les équipes.
• Avant de créer une nouvelle branche de version, exécutez git log --oneline main..release/1.0.
• Un cherry-pick crée un doublon : la même modification dans deux commits. --cherry-mark les signale avec =. Les modifications identiques fusionnent sans problème. Des corrections différentes pour un même bogue causent des conflits.
• Utilisez une seule source par correction, cherry-pick -x, et une règle d’équipe. Corrigez d’abord sur main, ou corrigez sur la branche de version puis faites une fusion de retour.
• Vous pouvez maintenant publier une version, la corriger avec un cherry-pick traçable et garder main et la branche de version cohérentes.

Leçon suivante : Travail final