Travail final

Après le module 5
environ 3 h

Ce que vous saurez faire

Montrez que vous pouvez utiliser Git en équipe du début à la fin. Vous travaillez dans un seul projet pratique, avec un coéquipier, et vous gardez des preuves de chaque étape.

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

Ce que vous devez savoir

Vous avez terminé les modules 1 à 5. Chaque partie ci-dessous indique les leçons qu’elle utilise.

Ce qu’il vous faut sur votre ordinateur

Le dépôt des exercices dans ~/projects/nextia-learning-labs. Si vous ne l’avez pas, clonez-le comme dans Les étapes d’une demande de tirage : préparer le laboratoire d’exercice. Pour obtenir la version la plus récente, exécutez git -C nextia-learning-labs pull dans ~/projects.
Git, avec votre nom et votre adresse courriel, selon Configurer Git : Étape 2 : indiquer votre identité à Git.
L’état d’exercice final. Vous le créez dans Préparation. Vous pouvez faire le travail en plusieurs séances. Votre travail reste dans ~/projects/c14-lab jusqu’à ce que vous exécutiez de nouveau le script de préparation.
Vous n’avez pas besoin de compte sur un site Web. Les demandes de tirage sont simulées, comme dans Les étapes d’une demande de tirage : la simulation dans cette leçon.

La situation

Vous êtes Amira. Sam et vous tenez les notes du centre d’assistance, qui utilise la version 1.0. Trois choses demandent votre attention :

Une note à mettre à jour. Il faut indiquer la prochaine action du billet 103.
Une erreur partagée. Un des commits (enregistrements de modifications) que Sam a poussés a supprimé un contact encore nécessaire au centre d’assistance.
Un bogue dans la version publiée. La version 1.0 contient le mauvais poste téléphonique pour l’équipe réseau. Le correctif doit parvenir au centre d’assistance sans le travail d’exportation inachevé qui se trouve sur main.

Préparation

Créez les dépôts d’exercice :

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

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 final --reset

Allez dans votre clone et consultez l’historique :

cd c14-lab/ticket-notes
git log --oneline --graph --all

* 0df72be (HEAD -> main, origin/main, origin/HEAD) Add ticket 105
* 0cc9f00 Remove old contacts
* 3cf73f7 Start the ticket export (not finished)
* 465d7ea (tag: v1.0.0, origin/release/1.0) Add escalation rules
* f330fdc Add ticket 104
* e058b3f Add ticket 103

Les empreintes correspondent, car le script a créé ces commits. Vos propres commits auront des empreintes différentes.

Créez le fichier de preuves. Il se trouve dans c14-lab, hors du dépôt, pour éviter de l’inclure dans un commit par accident :
Fenêtre de terminal
```
touch ../evidence.md
```

L’état de départ :

Référence	Pointe vers	Notes
`main`	`0df72be`	Votre clone. Sam a poussé un autre commit que vous n’avez pas encore récupéré.
`release/1.0` et l’étiquette `v1.0.0`	`465d7ea`	Ce que le centre d’assistance utilise. Le poste téléphonique `4410` de l’équipe réseau est incorrect. La bonne valeur est `4401`.
`3cf73f7`	sur `main`	Le travail d’exportation inachevé. Il ne doit pas entrer dans une version publiée.

Règles pour chaque partie

Faites chaque modification sur une branche. Fusionnez-la par une demande de tirage simulée : un fichier de description, une révision, la vérification, puis une fusion avec git merge --no-ff.
Écrivez chaque description de demande de tirage dans un fichier de c14-lab, par exemple ../pr-1.md. Utilisez la structure du module 3 : Source → cible, Problème, Modification, Comment j’ai vérifié.
Exécutez sh check.sh avant chaque fusion. Ne fusionnez pas si la vérification affiche FAIL (échec).
Ne forcez pas une poussée et ne réécrivez pas les commits qui sont sur le dépôt distant.
Après chaque partie, copiez les sorties demandées dans evidence.md.

Partie 1 : mettre à jour un billet par une demande de tirage

Utilise les modules 1 à 4 : Suivre une première modification, Les étapes d’une demande de tirage, Lire et réviser les différences et Les conflits, étape par étape.

Sur main, créez une branche appelée ticket-103-next-step.
Ajoutez ce texte à la fin de la ligne du billet 103 : Next: check the network switch. (Prochaine étape : vérifier le commutateur réseau.)
Créez un commit avec un message clair et poussez la branche avec -u.
Écrivez ../pr-1.md. Source → cible : ticket-103-next-step → main.
Faites la révision dans le rôle de Sam. Dans ../sam-notes, récupérez les changements, puis lisez les différences de la demande de tirage avec trois points. Ajoutez un commentaire de révision dans pr-1.md, sous le titre Révision.
Avant de fusionner, mettez votre branche à jour avec le dernier état de main. Dans ticket-notes, récupérez les changements, puis fusionnez origin/main dans ticket-103-next-step. Un conflit arrête la fusion.
Lisez les deux versions et les messages de commit avant de modifier le fichier. La ligne résolue doit garder le fait indiqué par Sam et votre prochaine action, dans un ordre logique.
Exécutez git diff --check et sh check.sh. Terminez ensuite la fusion et poussez la branche.
Passez à main, tirez les changements et fusionnez la branche avec git merge --no-ff. Exécutez la vérification, puis poussez main.
Supprimez la branche, localement et sur le dépôt distant.

Preuves pour la partie 1 :

pr-1.md, avec le commentaire de révision.
Le conflit : la sortie de git status --short pendant l’arrêt de la fusion et la ligne finale du billet 103.
git log --oneline --graph -6 sur main après l’étape 9.
git show --stat pour votre propre commit de l’étape 3. Il doit modifier seulement tickets.txt.

Partie 2 : annuler une erreur partagée

Utilise Annuler en toute sécurité et Récupérer son travail.

Faites cette partie avant la partie 3. Le correctif de la partie 3 modifie la ligne voisine du contact supprimé. Si le contact manque encore, le cherry-pick (copie d’un commit) de la partie 3 s’arrête sur un conflit.

Trouvez le commit qui a supprimé l’équipe Accounts. Utilisez git log --oneline -- contacts.txt, puis git show sur le commit que vous soupçonnez.
Créez une branche appelée restore-accounts-contact et annulez ce commit avec git revert.
Vérifiez que les commits ultérieurs de Sam sont toujours là : le billet 105 et sa modification du billet 103.
Écrivez ../pr-2.md (source → cible : restore-accounts-contact → main), puis fusionnez et poussez comme dans la partie 1.
Exercez-vous à récupérer du travail dans un clone jetable. Dans c14-lab, exécutez git clone team-remote.git scratch. Dans scratch, exécutez git reset --hard HEAD~2. Trouvez ensuite le commit perdu avec git reflog et ramenez main à ce commit. Supprimez scratch quand vous avez terminé.

Preuves pour la partie 2 :

La sortie de git show --stat pour le commit d’annulation, avec son message This reverts commit … (ceci annule le commit…).
Deux phrases : pourquoi vous avez utilisé revert et non reset sur main.
De l’étape 5 : les lignes de git reflog que vous avez utilisées et git log --oneline -3 après la récupération.

Partie 3 : réparer la version publiée

Utilise Branches de version et étiquettes, Appliquer un correctif avec cherry-pick et Garder des historiques cohérents.

Corrigez d’abord le bogue sur main. Créez une branche appelée fix-network-extension, remplacez 4410 par 4401 dans contacts.txt et créez un commit.
Écrivez ../pr-3.md (source → cible : fix-network-extension → main), puis fusionnez et poussez.
Trouvez l’empreinte du commit du correctif. Utilisez le commit de l’étape 1, pas le commit de fusion de l’étape 2.
Créez une branche locale release/1.0 avec git switch release/1.0. Créez ensuite hotfix/1.0.1 à partir de celle-ci.
Copiez le correctif avec git cherry-pick -x. Exécutez sh check.sh et poussez hotfix/1.0.1 avec -u.
Écrivez ../pr-4.md (source → cible : hotfix/1.0.1 → release/1.0). Sous Comment j’ai vérifié, montrez que la version publiée reçoit seulement le correctif.
Fusionnez hotfix/1.0.1 dans release/1.0 avec --no-ff. Créez l’étiquette annotée v1.0.1 sur le résultat.
Poussez release/1.0 et l’étiquette.

Preuves pour la partie 3 :

git log -1 --format=%B pour le commit copié par cherry-pick. Le message doit inclure (cherry picked from commit …) (copié depuis le commit…).
git diff --stat v1.0.0 v1.0.1. Seul contacts.txt change.
git show v1.0.1:export.txt. Git doit afficher fatal: path 'export.txt' does not exist in 'v1.0.1' (erreur fatale : le chemin « export.txt » n’existe pas dans « v1.0.1 »).
git log --oneline --cherry-mark main...release/1.0. Votre correctif apparaît deux fois, avec = devant chaque copie.
Une phrase : main a-t-elle maintenant besoin d’une fusion depuis release/1.0? Pourquoi ou pourquoi pas?

Vérifiez vos preuves

Pour chaque élément requis, choisissez le résultat qui correspond à vos preuves. Le cours est terminé quand les quatre éléments sont démontrés. Si un élément ne l’est pas, corrigez cette partie et vérifiez-la de nouveau. Vous pouvez recommencer autant de fois que nécessaire.

Élément requis	Démontré	Partiellement démontré	Pas encore démontré
*Des commits* (enregistrements de changements) clairs et un diff (comparaison des changements) lisible**	Chaque commit a un seul objectif et un message formulé comme une instruction. `git show --stat` montre uniquement les fichiers liés à cet objectif.	Les commits sont corrects, mais l’un combine deux changements ou a un message peu clair.	Les commits combinent des changements sans lien ou contiennent des fichiers à exclure, comme un fichier journal ou un secret.
*Un enchaînement correct des branches et des demandes de tirage (pull requests)*	Chaque changement était sur sa propre branche. Chaque fichier de demande de tirage indique la bonne source et la bonne cible. La vérification a réussi avant chaque fusion.	Un fichier de demande de tirage indique la mauvaise cible, mais la fusion s’est faite vers la bonne branche.	Un changement est allé directement dans `main` ou `release/1.0`, ou une fusion a eu lieu malgré le résultat `FAIL` (échec).
Un conflit résolu	La ligne finale conserve le fait rapporté par Sam et votre prochaine action. Aucun marqueur de conflit ne reste, et la vérification réussit.	Les deux faits sont conservés, mais la ligne est difficile à lire, ou vous n’avez pas exécuté la vérification.	Un des côtés est perdu, ou des marqueurs comme `<<<<<<<` se trouvent dans un commit.
Une récupération sûre	Le commit fautif est annulé sur `main`, et les commits suivants de Sam sont toujours là. Vous avez utilisé le reflog (journal des références) pour restaurer le clone de travail temporaire. Votre version contient la correction, sans le travail d’exportation.	L’annulation est correcte, mais votre explication de revert (annulation par un nouveau commit) et de reset (réinitialisation) manque ou est incorrecte.	Vous avez utilisé `reset` (réinitialisation) ou une poussée forcée sur une branche partagée, ou le travail suivant de Sam manque.

Tout élément comportant une action destructive sur l’historique partagé est pas encore démontré, même si le reste du travail est correct.

Afficher des exemples de preuves pour les étapes les plus difficiles

La ligne de Billet 103 après la résolution du conflit dans la partie 1 :

Ticket 103: shared drive is slow. Moved the user to the new server. Slow again on Monday. Next: check the network switch.

Le fait rapporté par Sam vient en premier, car il s’est produit en premier. Votre prochaine action en découle.

Pourquoi utiliser revert plutôt que reset (partie 2) : le commit fautif de Sam est dans le dépôt distant. D’autres commits le suivent. git reset ferait reculer main et supprimerait ces commits suivants. Le dépôt distant refuserait alors la poussée. git revert ajoute un nouveau commit qui annule uniquement le changement fautif. L’historique reste donc le même pour tout le monde.

Partie 3, la correction en double après la réparation de la version :

+ 68588d0 Merge branch 'fix-network-extension'
+ 932e885 Merge branch 'hotfix/1.0.1' into release/1.0
= dad18dd Fix the network team extension
= 0bdbe24 Fix the network team extension

Vos empreintes sont différentes. Les deux lignes = représentent le même changement avec deux empreintes. main contient déjà la correction, car vous l’avez d’abord faite là. Une fusion depuis release/1.0 n’est pas nécessaire pour cette correction. Beaucoup d’équipes fusionnent quand même la branche de version dans main. Ainsi, git log main..release/1.0 reste vide avant la prochaine version.

Erreur courante

Le cherry-pick indique que le commit est une fusion

Symptôme :

error: commit 68588d0965fe888faf1f203a298a52e85f52f227 is a merge but no -m option was given.
fatal: cherry-pick failed

Cause : vous avez fourni l’empreinte du commit de fusion de la partie 3, étape 2. Un commit de fusion a deux parents. Git ne sait donc pas quel changement copier.

Solution : exécutez git log --oneline main -4. Utilisez l’empreinte du commit portant votre message de correction, et non celle du commit Merge branch (fusion de branche). Relancez le cherry-pick (copie d’un commit précis).

Erreur courante

Le cherry-pick s'arrête sur un conflit dans contacts.txt

Symptôme : CONFLICT (content): Merge conflict in contacts.txt (conflit de contenu : conflit de fusion dans contacts.txt). Le fichier affiche Accounts team (équipe des comptes) d’un seul côté.

Cause : vous avez fait la partie 3 avant la partie 2. Vous avez fait votre correction alors que la ligne de l’équipe des comptes manquait. La version contient encore cette ligne, à côté de celle que vous avez modifiée.

Solution : exécutez git cherry-pick --abort. Faites la partie 2, puis refaites la correction sur main. Appliquez ensuite le nouveau commit de correction avec cherry-pick.

Travail supplémentaire facultatif

Ces tâches ne sont pas nécessaires pour terminer le cours.

Fusionnez release/1.0 dans main au moyen d’une demande de tirage. Vérifiez ensuite que git log --oneline main..release/1.0 est vide.
Refaites les parties 1 et 3 avec un dépôt privé sur GitHub et de vraies demandes de tirage. Comparez chaque étape avec la simulation.

Récapitulatif

Dans ce cours, vous avez appris à :

suivre et examiner les changements pour que chaque commit représente une étape claire;
travailler avec des branches et des demandes de tirage, et examiner un diff avant de l’approuver;
résoudre un conflit, et annuler ou récupérer du travail sans perdre les changements d’un coéquipier;
publier une version avec une branche et une étiquette, et y transférer une correction avec un cherry-pick traçable.