Einführung
Die nächste Aktualisierung des Gartenleitfadens betrifft zwei korrekte Angaben in derselben Zeile. Dein vorbereiteter Commit verlegt den Besuchereingang an den Südeingang und aktualisiert die Telefonnummer der Besucherinformation. Ein veröffentlichter Commit eines Teammitglieds ändert die Öffnungszeiten und den stufenlosen Zugangsweg. Der fertige Leitfaden benötigt beide Gruppen von Informationen.
Dieses Lab beginnt mit eigenen unabhängigen Repositories und benötigt keine Dateien aus der vorherigen VM. Du erlebst einen echten Inhaltskonflikt, übst den Abbruch eines unfertigen Merges, kombinierst die korrekten Felder und lieferst das Ergebnis an einen neuen empfangenden Klon aus.
Schließe das vorherige angeleitete Lab ab oder bringe bereits Kenntnisse über Remote-Namen, Fetch, Merge, Push und Klonen mit. Grundlegende Terminalnavigation, Commits und Diffs werden vorausgesetzt. Die Dauer von 45 Minuten ist eine Schätzung des Autors.
Einen Konflikt lesen und sicher neu starten
In diesem Schritt vergleichst du die beiden Beiträge, erkennst, warum das automatische Zusammenführen stoppt, und übst die sichere Rückkehr zum ursprünglichen lokalen Zustand.
Öffne Terminal und wechsle in das für dieses Lab unabhängig vorbereitete Repository:
cd /home/labex/project/guide-team/editor
Lege eine Identität nur für dieses Repository fest. --local verhindert Änderungen an globalen Einstellungen; die Anführungszeichen halten den Namen zusammen. Diese fiktiven Werte sind Beispiele und keine erforderlichen persönlichen Angaben:
git config --local user.name "Guide Editor"
git config --local user.email "guide@example.com"
Lies den vorbereiteten lokalen Leitfaden und rufe dann die Aktualisierung des Teammitglieds ab:
cat guide.txt
git fetch origin
Lies die Version des Teammitglieds. revision:path wählt eine tatsächlich im Commit gespeicherte Datei aus, und --no-pager gibt sie direkt aus:
git --no-pager show origin/main:guide.txt
Deine Version nennt South entrance mit 09:00-17:00; die des Teammitglieds nennt North entrance mit 10:00-18:00. Die fachlichen Entscheidungen sind unabhängig: Verwende deinen Südeingang und die neuen Öffnungszeiten des Teammitglieds. Erhalte den Satz zum letzten Einlass. Behalte auf den anderen Seiten deine Telefonnummer der Besucherinformation und die Rampe am Fluss aus dem Beitrag des Teammitglieds bei.
Starte den Merge. --no-edit verhindert das Öffnen eines Editors, falls ein Merge automatisch abgeschlossen wird. Hier soll der Befehl einen Status ungleich null zurückgeben und wegen eines Inhaltskonflikts anhalten. Führe ihn einzeln aus und fahre dann fort:
git merge --no-edit origin/main
Erwarte CONFLICT (content): Merge conflict in guide.txt und Automatic merge failed; fix conflicts and then commit the result. Git hat keinen neuen Commit erstellt.
Lies den kurzen Status und die Datei mit dem Konflikt:
git status --short
cat guide.txt
UU guide.txt bedeutet, dass die Datei noch nicht zusammengeführt wurde. In der Datei beginnt <<<<<<< HEAD deine Version, ======= trennt die Alternativen und >>>>>>> origin/main beendet die Version des Teammitglieds. Diese Markierungen beschreiben einen Widerspruch; würdest du nur die Markierungen löschen, blieben widersprüchliche Zeilen zurück. Die Seite mit dem Zugangsweg kann bereits als M access.txt vorgemerkt sein, weil Git diese unabhängige Änderung erfolgreich zusammengeführt hat.
Übe vor dem Auflösen die Wiederherstellung. git merge --abort bricht nur den unfertigen Merge ab und versetzt versionierte Dateien und Index in ihren Zustand vor dem Merge zurück. Diese Umgebung begann mit einem sauberen Arbeitsbaum; bei gewöhnlicher Arbeit solltest du unabhängige Änderungen vor einem Merge committen oder beiseitelegen.
git merge --abort
git status --short
Es sollten keine Änderungen erscheinen. Lies den Leitfaden erneut: Der ursprüngliche Südeingang und die alten Öffnungszeiten sind wieder da.
cat guide.txt
Starte nun denselben Merge erneut. Der Konflikt und der Status ungleich null werden erneut erwartet. Lasse diesen zweiten Konflikt für den nächsten Schritt offen:
git merge --no-edit origin/main
git status --short
Der Prüfpunkt erwartet einen aktiven, ungelösten Konflikt in guide.txt. Falls du einen Pfad falsch schreibst, verwende pwd und ls und kehre dann mit dem vollständigen cd-Befehl oben zurück. Lösche nicht .git und setze die VM nicht zurück, um einen gewöhnlichen Navigationsfehler zu beheben.
Die Angaben zusammenführen und den Merge abschließen
In diesem Schritt machst du aus dem Konflikt eine nutzbare Leitfadenzeile und behältst dabei die Seiten bei, die Git bereits zusammengeführt hat.
Bleibe in Terminal, in /home/labex/project/guide-team/editor, mit dem offenen Konflikt aus dem vorherigen Schritt. Du benötigst South entrance aus deinem Beitrag und 10:00-18:00 aus dem des Teammitglieds. Würdest du die gesamte Datei einer Seite übernehmen, ginge eine freigegebene Änderung verloren.
Der folgende Befehl ersetzt nur guide.txt durch ihr vollständiges dreizeiliges Ergebnis. > leitet die Ausgabe in diese Datei um und ersetzt ihren Inhalt. <<'GUIDE' ist ein Here-Dokument: Die folgenden Zeilen sind wörtliche Eingabe bis zu einer Zeile, die nur GUIDE enthält. Kopiere den gesamten Block einschließlich seiner abschließenden Markierung. Die Anführungszeichen um die Markierung verhindern Shell-Ersetzungen innerhalb des Texts. Programmierkenntnisse sind nicht erforderlich.
cat > guide.txt <<'GUIDE'
RIVERLIGHT GARDEN
Gate: South entrance; Hours: 10:00-18:00
Last entry is 30 minutes before closing.
GUIDE
Lies vor dem Vormerken alle drei Dateien. Der Satz zum letzten Einlass muss erhalten bleiben; access.txt muss die Rampe am Fluss enthalten; contacts.txt muss deine aktualisierte Telefonnummer enthalten.
cat guide.txt
cat access.txt
cat contacts.txt
Erwartete Inhalte der zusätzlichen Seiten:
Step-free route: Use the riverside ramp
Visitor desk: 010-555-0120
git add speichert die aufgelöste Datei im Index und markiert ihren Konflikt als gelöst. Der Befehl selbst erstellt noch keinen Commit:
git add guide.txt
Prüfe, was der Merge gegenüber deinem ursprünglichen lokalen Commit hinzufügen wird. diff --cached vergleicht das vorgemerkte Ergebnis mit HEAD; --no-pager hält die Ausgabe in diesem Terminal:
git --no-pager diff --cached
Erwarte die Änderung der Öffnungszeiten in guide.txt und die Änderung der Rampe in access.txt. Dein Südeingang und deine Besuchertelefonnummer waren bereits in deinem lokalen Vorgänger enthalten. Deshalb müssen sie in diesem Vergleich nicht als neu hinzugefügte Zeilen erscheinen. Prüfe neben diesem Diff auch die fertigen Dateien.
Falls du einen Schreibfehler siehst, wiederhole den vollständigen Leitfadenblock mit der Korrektur und führe erneut git add guide.txt aus. Falls du den unfertigen Versuch vollständig verwerfen möchtest, verwende git merge --abort aus dem vorherigen Schritt, starte den Merge erneut und wiederhole die Auflösung. Verwende den Abbruch nicht nach dem Abschluss des Commits.
Schließe den Merge mit einer aussagekräftigen Nachricht ab. -m übergibt die Nachricht direkt, statt einen Editor zu öffnen; andere sinnvolle Formulierungen werden akzeptiert:
git commit -m "Combine gate and opening hours"
Prüfe seine beiden Abstammungslinien und den sauberen Arbeitsbaum:
git --no-pager log --oneline --graph --all --decorate
git status --short
Es wird keine Statusausgabe erwartet. Beide ursprünglichen Beitragsnachrichten müssen unterhalb des neuen Merges erhalten bleiben. Der Prüfpunkt verlangt diesen Verlauf und vollständige korrekte Dateien, nicht bloß das Fehlen von Konfliktmarkierungen.
Den vollständigen Leitfaden veröffentlichen und empfangen
In diesem Schritt lieferst du die zusammengeführte Revision an das gemeinsame Repository aus und liest sie in einer neuen empfangenden Kopie. Ein lokaler Merge allein hat noch nichts an eine andere Kopie ausgeliefert.
Bleibe in Terminal, in /home/labex/project/guide-team/editor. push origin main sendet den lokalen Verlauf von main an das Repository namens origin. Dieses Mal ist der gemeinsame Beitrag ein Vorfahre deines Merges. Deshalb kann der Push den gemeinsamen main vorwärtsbewegen, ohne den Beitrag zu entfernen.
git push origin main
Erwarte main -> main ohne Ablehnung. Falls der Push abgelehnt wird, rufe den Verlauf erneut ab und prüfe den Graphen; füge keine Option zum Erzwingen hinzu. In dieser vorbereiteten Umgebung arbeitet kein Teammitglied im Hintergrund, aber in einem echten Team kann jederzeit neue Arbeit veröffentlicht werden.
Wechsle nun in das Verzeichnis, das beide Repositories enthält:
cd /home/labex/project/guide-team
git clone erstellt aus einer Quelle ein neues Repository samt Arbeitsdateien. Hier ist shared.git der vorhandene lokale Quellpfad und received-guide das neue Zielverzeichnis. Die empfangende Kopie muss vom gemeinsamen Repository ausgehen, damit sie zeigt, ob der Merge tatsächlich ausgeliefert wurde.
git clone shared.git received-guide
Erwarte Cloning into 'received-guide'... und done.. Falls du beim Experimentieren bereits einen Klon erstellt hast, behalte diese Kopie: Wechsle in received-guide und verwende das bereits erklärte git fetch origin, gefolgt von git merge --no-edit origin/main, um sie zu aktualisieren. Lösche nicht das ursprüngliche Bearbeitungs-Repository, um das Klonen erneut zu versuchen.
Wechsle in die empfangende Kopie:
cd received-guide
Lies jede tatsächliche Datei. cat gibt eine Datei aus, ohne sie zu ändern:
cat guide.txt
cat access.txt
cat contacts.txt
Vergleiche die Informationen mit den kombinierten fachlichen Anforderungen aus dem vorherigen Schritt. Alle drei Dateien müssen vollständig sein, einschließlich der unveränderten Zeilen. Eine Erfolgsmeldung beim Klonen allein beweist nicht, dass die Informationen korrekt sind.
Lies abschließend den Verlauf der empfangenden Kopie. --oneline verkürzt jeden Commit, --graph zeichnet seine Verbindungen zu den Vorgängern und --decorate beschriftet die Branch-Zeiger. --no-pager gibt die Ausgabe direkt aus, statt ein Anzeigeprogramm zum Blättern zu öffnen.
git --no-pager log --oneline --graph --decorate
Der oberste Merge besitzt zwei Abstammungslinien, einschließlich beider ursprünglicher Beitragsnachrichten und des ersten Commits. Deine genauen Commit-IDs variieren. Prüfe, dass kein Inhalt verloren gegangen ist und die empfangende Kopie auf main steht, ohne Änderungen an versionierten Dateien im Arbeitsbaum:
git status --short
Keine Ausgabe bedeutet, dass es weder vorgemerkte noch nicht vorgemerkte noch unversionierte Änderungen gibt. Du hast eine nutzbare Dateisammlung über tatsächliche Git-Repositories ausgeliefert, die alle auf diesem einen Übungsrechner liegen.
Zusammenfassung
Du hast beide Seiten eines echten Konflikts gelesen, mit git merge --abort sicher den Ausgangszustand wiederhergestellt und anschließend die korrekten Felder zusammengesetzt, statt eine Seite vollständig zu übernehmen. Du hast den automatisch zusammengeführten Zugangsweg, deine Besuchertelefonnummer und den unveränderten Satz im Leitfaden erhalten.
Der veröffentlichte Merge und der unabhängige empfangende Klon enthalten jetzt den vollständigen Leitfaden, wobei beide ursprünglichen Beiträge erhalten bleiben. Die Challenge verwendet ein anderes Handbuch und vertauscht, welcher Beitrag jeweils das korrekte Feld enthält.
