Introduction
Riverlight Garden a besoin d'un guide de visite correct. Votre commit local préparé déplace l'entrée et met à jour le numéro de téléphone de l'accueil. Un membre de l'équipe a déjà publié un nouvel itinéraire sans marches. Les visiteurs ont besoin de ces trois corrections.
Vous récupérerez le travail de votre collègue, fusionnerez les modifications indépendantes et publierez le résultat. Un nouveau clone récepteur vous donnera les fichiers réellement livrés. Le dépôt partagé et les deux copies sont des répertoires locaux sur une seule machine de formation ; il s'agit d'une véritable collaboration Git sans service hébergé, configuration de serveur ni compte.
Vous devez déjà reconnaître les commits, une branche, git add, git commit et une comparaison élémentaire des différences. Les noms de dépôts distants, la récupération, la fusion, l'envoi et le clonage sont expliqués ici. La durée de 35 minutes est une estimation de l'auteur qui inclut la lecture et les erreurs courantes.
Découvrir la mise à jour d'un membre de l'équipe
Dans cette étape, découvrez pourquoi votre mise à jour locale préparée ne peut pas encore être livrée, puis récupérez la révision de votre collègue sans modifier vos fichiers.
Ouvrez Terminal. Commencez dans le dépôt de travail préparé :
cd /home/labex/project/guide-team/editor
cd change le répertoire de travail de ce terminal. Si vous saisissez mal un chemin, utilisez pwd pour afficher votre répertoire courant et ls pour en lister le contenu, puis répétez la commande cd complète ci-dessus. Ces erreurs de navigation courantes ne nécessitent pas une nouvelle VM.
Un nouveau commit de fusion aura besoin d'une identité d'auteur. --local enregistre ces paramètres uniquement dans ce dépôt. Le texte entre guillemets constitue une seule valeur, même s'il contient des espaces ; l'adresse e-mail d'exemple est fictive. Vous pouvez choisir votre propre nom et votre propre adresse e-mail.
git config --local user.name "Guide Editor"
git config --local user.email "guide@example.com"
Votre commit local existant est déjà complet. Lisez ses informations destinées aux visiteurs :
cat guide.txt
cat contacts.txt
Vous devez voir South entrance et le numéro d'accueil 010-555-0120. Conservez la phrase sur la dernière admission dans le guide. Le fichier d'itinéraire séparé indique encore Use the north ramp :
cat access.txt
git status --short donne une liste compacte des fichiers modifiés. Ici, l'absence de sortie signifie que la contribution préparée est enregistrée dans un commit et que l'arbre de travail est propre :
git status --short
Un dépôt distant, ou remote, est une connexion nommée vers un autre dépôt. origin est le nom de cette connexion, et non un serveur particulier. -v affiche ses adresses de récupération et d'envoi :
git remote -v
Les deux adresses pointent vers /home/labex/project/guide-team/shared.git. C'est un dépôt nu : il stocke l'historique partagé sans copie de travail modifiable. Ne modifiez pas ses fichiers internes.
Essayez de livrer votre branche. push envoie des commits ; main désigne la branche à mettre à jour sur origin. Ce premier envoi doit échouer avec un code de sortie non nul. Exécutez la commande seule, puis continuez après le refus :
git push origin main
Repérez [rejected], main -> main et (fetch first). La branche partagée contient du travail absent de votre historique courant ; Git refuse donc de la remplacer. Il s'agit d'une mise à jour sans avance rapide : la pointe partagée existante n'est pas un ancêtre de la pointe proposée. Un envoi forcé retirerait la contribution de votre collègue de la branche et contreviendrait à cette tâche.
fetch télécharge les commits distants et met à jour un pointeur local de suivi distant, origin/main. Cette commande ne les fusionne pas dans votre propre branche main et ne réécrit pas vos fichiers de travail :
git fetch origin
Comparez les historiques. --oneline affiche une ligne courte par commit ; --graph dessine les liens de parenté ; --all inclut les branches locales et celles de suivi distant ; --decorate ajoute leurs étiquettes. --no-pager affiche directement la sortie ; si vous ouvrez un visualiseur en expérimentant, appuyez sur q pour le quitter.
git --no-pager log --oneline --graph --all --decorate
Repérez Move the gate and update the visitor desk sur HEAD -> main et Update the step-free route sur origin/main. Tous deux descendent de Open the garden guide. HEAD désigne le commit actuellement extrait. Les deux contributions diffèrent ; aucune ne remplace l'autre.
Lisez l'itinéraire de votre collègue directement dans son instantané. show accepte une expression revision:path ; origin/main:access.txt désigne donc ce fichier dans la révision récupérée :
git --no-pager show origin/main:access.txt
Il indique Use the riverside ramp. Votre fichier d'itinéraire de travail indique encore Use the north ramp. Cette différence prouve que la récupération a rendu le nouvel historique disponible tout en laissant votre arbre de travail intact. Le premier point de contrôle accepte cette révision récupérée lorsque votre commit local d'origine est toujours intact.
Combiner les contributions indépendantes
Dans cette étape, combinez les deux historiques en une révision contenant l'entrée sud, le numéro de téléphone des visiteurs mis à jour et la rampe au bord de la rivière.
Restez dans Terminal, dans /home/labex/project/guide-team/editor. Une fusion combine des historiques. Comme ces modifications touchent des fichiers différents, Git peut combiner leur texte automatiquement. --no-edit accepte le message de fusion généré par Git et évite d'ouvrir un éditeur :
git merge --no-edit origin/main
Vous devez obtenir un résumé de fusion réussie, généralement Merge made by the 'ort' strategy.. Git crée un commit de fusion avec deux parents : votre commit d'origine et celui de votre collègue. Aucune contribution n'est réécrite.
Lisez les véritables fichiers combinés :
cat guide.txt
cat access.txt
cat contacts.txt
Le guide doit conserver South entrance, 09:00-17:00 et la phrase sur la dernière admission ; l'itinéraire doit indiquer Use the riverside ramp ; le téléphone doit rester 010-555-0120. Les modifications indépendantes ont été combinées sans conflit, mais vous devez encore en évaluer le sens.
Examinez l'historique obtenu :
git --no-pager log --oneline --graph --all --decorate
La fusion à HEAD -> main réunit les deux lignes de contribution. origin/main continue de désigner le commit de votre collègue précédemment récupéré jusqu'à l'envoi. C'est normal : la fusion a modifié la branche main locale, et non la branche main partagée.
Vérifiez l'état de travail :
git status --short
Aucune sortie n'est attendue. Si une autre expérimentation a laissé une fusion en cours, git merge --abort annule cette fusion inachevée et restaure l'état antérieur ; exécutez cette commande uniquement pendant une fusion en cours, puis répétez la commande de fusion. Elle n'annule pas un commit déjà terminé. Le point de contrôle exige un commit de fusion combiné avec les deux parents d'origine et les trois fichiers complets.
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 traité un véritable refus d'envoi, récupéré le commit d'un membre de l'équipe sans écraser vos propres fichiers, fusionné deux contributions indépendantes et livré le guide complet à travers un dépôt partagé. Un véritable clone récepteur contenait le guide combiné, l'itinéraire sans marches et les coordonnées pour les visiteurs.
Les commits d'origine restent dans l'historique. Exercez-vous ensuite à une fusion où Git a besoin de votre jugement parce que les deux personnes ont modifié la même ligne.
