Introduction
Le guide Harbour Loop pris en charge a besoin d'une correction du lien de téléchargement. Le développement contient déjà cette correction, ainsi qu'une refonte Explorer non approuvée. L'arbre de travail principal d'origine contient toujours du travail préparé pour le plan photo, un brouillon supplémentaire non préparé de couverture et une note privée non suivie.
Utilisez la technique du worktree du premier atelier guidé pour donner à la branche de maintenance existante un répertoire de travail propre. Lisez les véritables patches, sélectionnez l'unique correction autonome et rejouez uniquement cette modification avec cherry-pick. Testez ensuite le téléchargement utile de l'ancienne édition et vérifiez que ni la refonte ni votre travail inachevé n'ont été intégrés à la version.
Cette unité initialise ses propres dépôts et fichiers ; elle ne réutilise pas la VM précédente. Les prérequis sont les bases du terminal, des commits, des branches et de log/diff, ainsi que les concepts de worktree lié et de petit fichier enseignés dans le premier atelier guidé. Aucun code de site web ni compte hébergé n'est nécessaire. Utilisez Workspace et Release Desk. Le véritable aperçu Git/HTTP est local à une seule machine de formation et lit les commits des branches, et non les modifications des fichiers de travail. Tous les itinéraires et toutes les identités sont fictifs. La durée de 40 minutes est une estimation de l'auteur.
Identifier la correction et ouvrir le worktree de maintenance
Dans cette étape, découvrez le téléchargement attendu, distinguez la correction isolée de la refonte et ouvrez l'ancienne branche existante sans perturber main.
Ouvrez Release Desk, puis Open supported release. Vérifiez Harbour Loop, Pocket Edition 1.0, 3.2 km et North Pier. Utilisez Download quick start, ouvrez quick-start.txt depuis la liste des téléchargements du navigateur et vérifiez le point de rendez-vous d'origine et la courte liste de préparation.
Utilisez Download full guide. La véritable page 404 Guide not found est attendue, puis cliquez sur Back to release. Le service est accessible, mais le lien de cette version pointe vers un fichier qu'elle ne contient pas.
Utilisez All releases, puis Open development preview. Explorer Edition 2.0 n'est pas approuvée. Son lien Download full guide fonctionne déjà : ouvrez harbour-guide-v1.txt depuis votre liste des téléchargements et lisez les trois indications d'origine, le départ de North Pier, la distance de 3.2 km et le rappel concernant les sentiers et les déchets. Conservez cette correction utile en laissant la refonte de côté. Utilisez All releases pour revenir.
Passez à Workspace et entrez explicitement dans le répertoire de travail d'origine :
cd /home/labex/project/release-desk/editor
Pour les erreurs de chemin courantes, utilisez pwd et ls, puis répétez cette commande cd complète ; ne réinitialisez pas la VM. Définissez une identité d'auteur propre au dépôt. --local concerne ce dépôt et ses worktrees liés, et non la configuration globale. Vous pouvez remplacer les exemples fictifs entre guillemets :
git config --local user.name "Guide Editor"
git config --local user.email "guides@example.com"
Lisez l'état inachevé avant d'effectuer la maintenance :
git branch --show-current
git status --short
git --no-pager diff --cached -- preview.txt
git --no-pager diff -- preview.txt
cat private-note.txt
Comme dans le premier atelier, vous devez obtenir main, MM preview.txt et ?? private-note.txt. La première comparaison montre l'ajout préparé Plan: add dusk photographs.. La seconde montre l'ajout supplémentaire non préparé Draft: try the violet cover.. Conservez leurs contenus distincts et la note privée. --cached sélectionne la comparaison entre index et commit ; la comparaison simple compare les fichiers de travail à l'index. --no-pager affiche directement la sortie et -- sépare le chemin qui suit.
Lisez l'historique enregistré du développement. --oneline abrège chaque entrée et --decorate ajoute les étiquettes des pointeurs et des tags :
git --no-pager log --oneline --decorate dev-start
Le tag fixe dev-start marque la pointe héritée de main. Du plus récent au plus ancien, l'historique préparé contient Plan the Explorer photo collection, Correct the Harbour Loop download link, Introduce the Explorer redesign et Prepare the supported Harbour Loop guide. Gardez le tag et la pointe de main inchangés.
Inspectez la dernière modification avant de la choisir. show affiche un commit sélectionné et son patch :
git --no-pager show dev-start
Il modifie explorer-plan.txt. C'est du travail futur sans rapport. La correction se trouve un parent avant ce repère fixe. ~1 sélectionne ce parent sans modifier votre extraction :
git --no-pager show dev-start~1
Son patch complet modifie uniquement le fichier d'une ligne full-guide.path : /downloads/harbour-guid-v1.txt devient /downloads/harbour-guide-v1.txt. Cette correction est autonome ; elle n'exige pas la refonte. Inspectez aussi cette refonte antérieure. ~2 remonte de deux étapes dans la chaîne des parents à partir du repère fixe et sélectionne un seul commit ancêtre :
git --no-pager show dev-start~2
Elle change l'identité de la version et ajoute des plans Explorer. Fusionner la branche de développement entière importerait ces modifications non approuvées en plus de la correction utile.
Ouvrez la branche prise en charge existante à côté de main. .. désigne le répertoire parent et le second argument choisit explicitement la branche existante au lieu d'en créer une nouvelle à partir de main :
git worktree add ../supported-v1 release/1.0
git worktree list
cd ../supported-v1
git branch --show-current
git status --short
cat release.txt
Vous devez retrouver les deux répertoires dans la liste native des worktrees, la branche release/1.0, un état de maintenance propre et l'identité Pocket Edition 1.0. Son index séparé donne à cherry-pick la cible propre nécessaire tandis que le brouillon de main reste en place. Si vous demandez par erreur d'ajouter de nouveau main, le refus de branche déjà extraite enseigné dans le premier atelier ne nécessite ni forçage ni reset : inspectez git worktree list et utilisez la branche prise en charge existante.
Appliquer la correction et vérifier la version préservée
Dans cette étape, rejouez uniquement le patch sélectionné sur l'ancienne version, testez le véritable guide et confirmez que le travail de développement d'origine est intact.
Restez dans Workspace, dans /home/labex/project/release-desk/supported-v1. Un cherry-pick prend la modification introduite par un commit sélectionné et l'applique sur votre branche courante, en enregistrant normalement un nouveau commit. Il ne fusionne pas tous les ancêtres du commit sélectionné. Dans ce scénario, l'ancienne branche possède un parent différent de celui de la correction source ; la nouvelle correction a donc son propre identifiant de commit.
Lisez une fois l'ancien lien, puis appliquez la correction isolée inspectée. Le tag reste visible depuis les deux worktrees liés, car les objets et les références du dépôt sont partagés :
cat full-guide.path
git cherry-pick dev-start~1
Vous devez obtenir un nouveau commit avec le sujet du lien de téléchargement et la modification d'un seul fichier, sans conflit. Ce patch préparé change le même petit paramètre sur la base prise en charge ; il n'a aucune chaîne de dépendances. Votre identifiant de commit peut différer.
Examinez exactement ce qu'a reçu la branche de maintenance. Le tag fixe supported-start marque l'ancienne pointe héritée, HEAD est le commit courant de ce worktree et diff compare ces instantanés :
git --no-pager diff supported-start HEAD
Seule la correction du chemin du guide complet doit apparaître. Il ne doit y avoir aucune modification de release.txt, du contenu du guide ni du texte d'aperçu d'origine, ni aucun fichier réservé à Explorer. Inspectez le véritable historique et l'état propre de la cible :
git --no-pager log --oneline --decorate
git status --short
cat release.txt
Il doit y avoir une correction directement après le commit pris en charge d'origine. Les commits de refonte et de plan photo du développement sont absents de l'ascendance de cette branche. La formulation exacte du message n'est pas le critère de réussite ; ce sont le patch isolé, la bonne base et les fichiers préservés qui comptent.
Passez à Release Desk, cliquez sur Release Desk dans l'en-tête pour revenir à la vue d'ensemble, puis sur Open supported release. L'aperçu doit conserver Pocket Edition 1.0, Harbour Loop, 3.2 km et North Pier. L'aperçu local lit le commit de branche que vous venez de faire avancer ; aucun déploiement distant ni en production n'est simulé.
Cliquez sur Download full guide. Ouvrez le véritable fichier harbour-guide-v1.txt depuis la liste des téléchargements de votre navigateur. Comparez son contenu complet au téléchargement lu précédemment depuis le développement : départ de North Pier ; les trois indications passant par Clock Steps, l'ancien hangar à bateaux et Anchor Square ; 3.2 km ; et le rappel final concernant les sentiers et les déchets. La correction livre le guide pris en charge d'origine, et non un nouvel itinéraire Explorer. Le lien de téléchargement seul ou un code d'état de réussite ne prouverait pas que le contenu est complet.
Utilisez Download quick start et conservez sa liste de préparation d'origine. Depuis All releases, ouvrez l'aperçu de développement et confirmez qu'Explorer Edition 2.0 est inchangée. Revenez avec All releases.
Passez à Workspace et rentrez dans le répertoire d'origine de main. Se trouver dans un autre répertoire change l'index de worktree que vos commandes inspectent. L'option de journal -1 limite la sortie au commit le plus récent :
cd /home/labex/project/release-desk/editor
git branch --show-current
git --no-pager log -1 --oneline --decorate
git status --short
git --no-pager diff --cached -- preview.txt
git --no-pager diff -- preview.txt
cat private-note.txt
Le commit le plus récent doit toujours être le commit de plan photo d'origine marqué dev-start. Vous devez retrouver les états d'origine de main MM preview.txt et ?? private-note.txt, la même phrase préparée du plan photo, la phrase distincte non préparée de la couverture violette et la note privée inchangée. Ne les enregistrez pas dans un commit et ne les supprimez pas simplement pour obtenir un état propre. Laissez le worktree pris en charge disponible. Le point de contrôle vérifie la relation de liaison, l'historique pris en charge et chaque fichier requis, ainsi que les véritables téléchargements et la préservation de main.
Résumé
Vous avez inspecté les véritables patches du développement, sélectionné la correction isolée du lien et l'avez rejouée avec cherry-pick dans le worktree de maintenance propre. L'ancienne version a reçu une correction utile sans hériter de la refonte.
Les téléchargements du guide complet et du démarrage rapide sont restés complets, tandis que la pointe de branche du développement, les versions préparée et non préparée du brouillon et la note privée sont restées intactes. Le challenge indépendant change la branche prise en charge, le guide et la position de la correction : sélectionnez-la donc à partir des preuves plutôt qu'en recopiant un décalage.
