Introduction
La prochaine mise à jour du guide du jardin concerne deux informations correctes sur une même ligne. Votre commit préparé dirige les visiteurs vers l'entrée sud et met à jour le téléphone de l'accueil. Le commit publié par un membre de l'équipe modifie les horaires d'ouverture et l'itinéraire sans marches. Le guide final a besoin de ces deux ensembles d'informations.
Cet atelier commence avec ses propres dépôts indépendants ; il ne nécessite aucun fichier de la VM précédente. Vous verrez un véritable conflit de contenu, vous vous exercerez à annuler une fusion inachevée, vous combinerez les bons champs et vous livrerez le résultat à un nouveau clone récepteur.
Terminez l'atelier guidé précédent, ou maîtrisez déjà les noms de dépôts distants, la récupération, la fusion, l'envoi et le clonage. Les bases de la navigation dans le terminal, des commits et des différences sont des prérequis. La durée de 45 minutes est une estimation de l'auteur.
Lire un conflit et le relancer en toute sécurité
Dans cette étape, comparez les deux contributions, voyez pourquoi la fusion automatique s'arrête et exercez-vous à revenir sans risque à l'état local d'origine.
Ouvrez Terminal et entrez dans le dépôt préparé indépendamment pour cet atelier :
cd /home/labex/project/guide-team/editor
Définissez une identité uniquement pour ce dépôt. --local évite de modifier les paramètres globaux ; les guillemets maintiennent le nom ensemble. Ces valeurs fictives sont des exemples, et non des renseignements personnels obligatoires :
git config --local user.name "Guide Editor"
git config --local user.email "guide@example.com"
Lisez le guide local préparé, puis récupérez la mise à jour de votre collègue :
cat guide.txt
git fetch origin
Lisez la version de votre collègue. revision:path sélectionne un véritable fichier enregistré dans un commit et --no-pager l'affiche directement :
git --no-pager show origin/main:guide.txt
Votre version indique South entrance avec 09:00-17:00 ; celle de votre collègue indique North entrance avec 10:00-18:00. Les décisions métier sont indépendantes : utilisez votre entrée sud et les nouveaux horaires de votre collègue. Préservez la phrase sur la dernière admission. Conservez votre téléphone d'accueil et la rampe au bord de la rivière de votre collègue depuis leurs autres pages.
Lancez la fusion. --no-edit évite un éditeur si une fusion se termine automatiquement. Ici, la commande doit renvoyer un code non nul et s'arrêter sur un conflit de contenu. Exécutez-la seule, puis continuez :
git merge --no-edit origin/main
Vous devez obtenir CONFLICT (content): Merge conflict in guide.txt et Automatic merge failed; fix conflicts and then commit the result. Git n'a pas créé de nouveau commit.
Lisez l'état abrégé et le fichier en conflit :
git status --short
cat guide.txt
UU guide.txt signifie que le fichier n'est pas fusionné. Dans le fichier, <<<<<<< HEAD commence votre version, ======= sépare les variantes et >>>>>>> origin/main termine la version de votre collègue. Ces marqueurs décrivent un désaccord ; supprimer uniquement les marqueurs laisserait des lignes contradictoires. La page de l'itinéraire peut déjà être préparée sous la forme M access.txt, car Git a fusionné cette modification indépendante avec succès.
Avant de résoudre le conflit, exercez-vous à la récupération. git merge --abort annule uniquement la fusion inachevée, en ramenant les fichiers suivis et l'index à leur état antérieur à la fusion. Ce scénario a commencé avec un état propre ; dans votre travail habituel, enregistrez dans un commit ou mettez de côté les modifications sans rapport avant de lancer une fusion.
git merge --abort
git status --short
Aucune modification ne doit apparaître. Relisez le guide : l'entrée sud d'origine et les anciens horaires sont de retour.
cat guide.txt
Relancez maintenant la même fusion. Le conflit et le code non nul sont de nouveau attendus. Laissez ce second conflit ouvert pour l'étape suivante :
git merge --no-edit origin/main
git status --short
Le point de contrôle attend un conflit actif non résolu dans guide.txt. Si vous saisissez mal un chemin, utilisez pwd et ls, puis revenez avec la commande cd complète ci-dessus. Ne supprimez pas .git et ne réinitialisez pas la VM pour corriger une erreur de navigation courante.
Résoudre les informations et terminer la fusion
Dans cette étape, transformez le conflit en une ligne de guide utilisable, tout en conservant les pages déjà fusionnées par Git.
Restez dans Terminal, dans /home/labex/project/guide-team/editor, avec le conflit de l'étape précédente ouvert. Vous avez besoin de South entrance de votre contribution et de 10:00-18:00 de celle de votre collègue. Choisir le fichier entier d'un côté ou de l'autre ferait perdre une modification approuvée.
La commande suivante remplace uniquement guide.txt par son résultat complet de trois lignes. > redirige la sortie vers ce fichier, en remplaçant son contenu. <<'GUIDE' est un here-document : les lignes suivantes sont une entrée littérale jusqu'à une ligne contenant uniquement GUIDE. Copiez le bloc entier, y compris son marqueur final. Les guillemets autour du marqueur empêchent l'expansion par le shell dans le texte. Aucune programmation n'est nécessaire.
cat > guide.txt <<'GUIDE'
RIVERLIGHT GARDEN
Gate: South entrance; Hours: 10:00-18:00
Last entry is 30 minutes before closing.
GUIDE
Lisez les trois fichiers avant la préparation. La phrase sur la dernière admission doit rester ; access.txt doit contenir la rampe au bord de la rivière ; contacts.txt doit contenir votre téléphone mis à jour.
cat guide.txt
cat access.txt
cat contacts.txt
Contenu attendu des pages supplémentaires :
Step-free route: Use the riverside ramp
Visitor desk: 010-555-0120
git add enregistre le fichier résolu dans l'index et marque son conflit comme résolu. Cette commande ne crée pas elle-même de commit :
git add guide.txt
Examinez ce que la fusion ajoutera par rapport à votre commit local d'origine. diff --cached compare le résultat préparé à HEAD ; --no-pager conserve la sortie dans ce terminal :
git --no-pager diff --cached
Vous devez voir la modification des horaires dans guide.txt et celle de la rampe dans access.txt. Votre entrée sud et votre téléphone pour les visiteurs figuraient déjà dans le parent local ; ils n'ont donc pas à apparaître comme de nouvelles lignes dans cette comparaison. Vérifiez les fichiers finaux en plus de cette comparaison.
Si vous voyez une faute de frappe, répétez le bloc complet du guide avec la correction et exécutez à nouveau git add guide.txt. Si vous voulez abandonner entièrement la tentative inachevée, utilisez git merge --abort de l'étape précédente, relancez la fusion et répétez la résolution. N'utilisez pas l'annulation après avoir terminé le commit.
Terminez la fusion avec un message descriptif. -m fournit directement le message au lieu d'ouvrir un éditeur ; toute autre formulation pertinente est acceptée :
git commit -m "Combine gate and opening hours"
Inspectez ses deux lignes d'ascendance et son arbre de travail propre :
git --no-pager log --oneline --graph --all --decorate
git status --short
Aucune sortie d'état n'est attendue. Les messages des deux contributions d'origine doivent rester sous la nouvelle fusion. Le point de contrôle exige cet historique et des fichiers corrects et complets, pas seulement l'absence de marqueurs de conflit.
Publier et recevoir le guide complet
Dans cette étape, livrez la révision fusionnée au dépôt partagé et lisez-la depuis une nouvelle copie réceptrice. Une fusion locale seule n'a encore rien livré à une autre copie.
Restez dans Terminal, dans /home/labex/project/guide-team/editor. push origin main envoie l'historique de la branche main locale au dépôt nommé origin. Cette fois, la contribution partagée est un ancêtre de votre fusion ; l'envoi peut donc faire avancer la branche main partagée sans retirer cette contribution.
git push origin main
Vous devez obtenir main -> main sans refus. En cas de refus, récupérez à nouveau l'historique et inspectez le graphe ; n'ajoutez pas d'option de forçage. Ce scénario préparé n'a aucun contributeur actif en arrière-plan, mais une véritable équipe peut publier du nouveau travail à tout moment.
Passez maintenant au répertoire contenant les deux dépôts :
cd /home/labex/project/guide-team
git clone crée un nouveau dépôt et des fichiers de travail à partir d'une source. Ici, shared.git est le chemin source local existant et received-guide est le nouveau répertoire de destination. La copie réceptrice doit partir du dépôt partagé : elle révélera ainsi si la fusion a réellement été livrée.
git clone shared.git received-guide
Vous devez obtenir Cloning into 'received-guide'... et done.. Si vous avez déjà effectué le clonage en expérimentant, conservez cette copie : entrez dans received-guide et utilisez git fetch origin, déjà enseigné, puis git merge --no-edit origin/main pour la mettre à jour. Ne supprimez pas le dépôt de travail d'origine pour réessayer un clonage.
Entrez dans la copie réceptrice :
cd received-guide
Lisez chaque fichier réel. cat affiche un fichier sans le modifier :
cat guide.txt
cat access.txt
cat contacts.txt
Comparez les informations aux exigences métier combinées de l'étape précédente. Les trois fichiers doivent être complets, y compris les lignes inchangées. Un message de clonage réussi ne suffit pas à prouver que les informations sont correctes.
Enfin, lisez l'historique de la copie réceptrice. --oneline abrège chaque commit, --graph dessine ses liens de parenté et --decorate ajoute les étiquettes des pointeurs de branche. --no-pager affiche directement la sortie au lieu d'ouvrir un visualiseur défilant.
git --no-pager log --oneline --graph --decorate
La fusion au sommet possède deux lignes d'ascendance, comprenant les messages des deux contributions d'origine et le commit initial. Vos identifiants exacts de commits varient. Vérifiez qu'aucun contenu n'a été perdu et que la copie réceptrice est sur main, avec un arbre de travail propre pour les fichiers suivis :
git status --short
L'absence de sortie signifie qu'il n'y a aucune modification préparée, non préparée ou non suivie. Vous avez livré un ensemble de fichiers utilisable à travers de véritables dépôts Git, tous présents sur cette seule machine de formation.
Résumé
Vous avez lu les deux côtés d'un véritable conflit, utilisé git merge --abort pour revenir en arrière sans risque, puis composé les bons champs au lieu de choisir un côté entier. Vous avez conservé l'itinéraire fusionné automatiquement, votre téléphone pour les visiteurs et la phrase inchangée du guide.
La fusion publiée et le clone récepteur indépendant contiennent maintenant le guide complet, avec les deux contributions d'origine préservées. Le challenge change le manuel et inverse le contributeur qui possède chaque champ correct.
