Einführung
Riverlight Garden benötigt einen korrekten Besucherleitfaden. Dein vorbereiteter lokaler Commit verlegt den Eingang und aktualisiert die Telefonnummer der Besucherinformation. Ein Teammitglied hat bereits einen neuen stufenlosen Zugangsweg veröffentlicht. Die Besucher brauchen alle drei Korrekturen.
Du rufst die Arbeit des Teammitglieds ab, führst die unabhängigen Änderungen zusammen und veröffentlichst das Ergebnis. Ein neuer empfangender Klon liefert dir die tatsächlich ausgelieferten Dateien. Das gemeinsame Repository und beide Kopien sind lokale Verzeichnisse auf einem einzigen Übungsrechner. Es handelt sich um echte Zusammenarbeit mit Git, ohne gehosteten Dienst, Servereinrichtung oder Konto.
Du solltest bereits Commits, einen Branch, git add, git commit und einen einfachen Diff kennen. Remote-Namen sowie Fetch, Merge, Push und Klonen werden hier erklärt. Die Dauer von 35 Minuten ist eine Schätzung des Autors einschließlich Lesezeit und gewöhnlicher Fehler.
Die Aktualisierung des Teammitglieds entdecken
In diesem Schritt findest du heraus, warum deine vorbereitete lokale Aktualisierung noch nicht ausgeliefert werden kann. Anschließend rufst du die Revision des Teammitglieds ab, ohne deine Dateien zu ändern.
Öffne Terminal. Beginne im vorbereiteten Bearbeitungs-Repository:
cd /home/labex/project/guide-team/editor
cd ändert das Arbeitsverzeichnis dieses Terminals. Falls du einen Pfad falsch schreibst, gib mit pwd dein aktuelles Verzeichnis und mit ls dessen Inhalt aus. Wiederhole dann den vollständigen cd-Befehl oben. Solche gewöhnlichen Navigationsfehler erfordern keine neue VM.
Ein neuer Merge-Commit benötigt eine Autorenidentität. --local speichert diese Einstellungen nur in diesem Repository. Der Text in Anführungszeichen ist auch dann ein einzelner Wert, wenn er Leerzeichen enthält; die Beispiel-E-Mail-Adresse ist fiktiv. Du kannst einen eigenen Namen und eine eigene E-Mail-Adresse wählen.
git config --local user.name "Guide Editor"
git config --local user.email "guide@example.com"
Dein vorhandener lokaler Commit ist bereits vollständig. Lies seine Besucherinformationen:
cat guide.txt
cat contacts.txt
Du solltest South entrance und für die Besucherinformation 010-555-0120 sehen. Erhalte im Leitfaden den Satz zum letzten Einlass. In der separaten Datei für den Zugangsweg steht noch Use the north ramp:
cat access.txt
git status --short zeigt eine kompakte Liste geänderter Dateien. Keine Ausgabe bedeutet hier, dass der vorbereitete Beitrag committet und der Arbeitsbaum sauber ist:
git status --short
Ein Remote ist eine benannte Verbindung zu einem anderen Repository. origin ist der Name dieser Verbindung, kein besonderer Server. -v zeigt ihre Fetch- und Push-Adressen:
git remote -v
Beide Adressen zeigen auf /home/labex/project/guide-team/shared.git. Dies ist ein Bare-Repository: Es speichert den gemeinsamen Verlauf ohne bearbeitbare Arbeitskopie. Bearbeite seine internen Dateien nicht.
Versuche, deinen Branch auszuliefern. push sendet Commits; main bezeichnet den Branch, der bei origin aktualisiert werden soll. Dieser erste Push soll mit einem Exit-Status ungleich null fehlschlagen. Führe ihn einzeln aus und fahre nach der Ablehnung fort:
git push origin main
Achte auf [rejected], main -> main und (fetch first). Der gemeinsame Branch enthält Arbeit, die in deinem aktuellen Verlauf fehlt. Deshalb weigert sich Git, ihn zu ersetzen. Dies ist eine Non-Fast-Forward-Aktualisierung: Die vorhandene gemeinsame Branch-Spitze ist kein Vorfahre der vorgeschlagenen Spitze. Ein erzwungener Push würde den Beitrag des Teammitglieds aus dem Branch entfernen und gegen diese Aufgabe verstoßen.
fetch lädt Remote-Commits herunter und aktualisiert einen lokalen Remote-Tracking-Zeiger, origin/main. Der Befehl führt sie weder mit deinem eigenen main zusammen noch überschreibt er deine Arbeitsdateien:
git fetch origin
Vergleiche die Verläufe. --oneline zeigt pro Commit eine kurze Zeile; --graph zeichnet die Verbindungen zu den Vorgängern; --all bezieht lokale und Remote-Tracking-Branches ein; --decorate ergänzt ihre Beschriftungen. --no-pager gibt die Ausgabe direkt aus; falls du beim Experimentieren ein Anzeigeprogramm öffnest, verlässt du es mit q.
git --no-pager log --oneline --graph --all --decorate
Suche nach Move the gate and update the visitor desk auf HEAD -> main und nach Update the step-free route auf origin/main. Beide stammen von Open the garden guide ab. HEAD bezeichnet den aktuell ausgecheckten Commit. Die beiden Beiträge unterscheiden sich; keiner ersetzt den anderen.
Lies den Zugangsweg des Teammitglieds direkt aus dessen Snapshot. show akzeptiert einen Ausdruck der Form revision:path; origin/main:access.txt bezeichnet also diese Datei in der abgerufenen Revision:
git --no-pager show origin/main:access.txt
Dort steht Use the riverside ramp. In deiner Arbeitsdatei für den Zugangsweg steht weiterhin Use the north ramp. Dieser Unterschied zeigt, dass Fetch den neuen Verlauf verfügbar gemacht hat, ohne deinen Arbeitsbaum zu verändern. Der erste Prüfpunkt akzeptiert diese abgerufene Revision, während dein ursprünglicher lokaler Commit unverändert erhalten bleibt.
Die unabhängigen Beiträge zusammenführen
In diesem Schritt führst du die beiden Verläufe zu einer Revision zusammen, die den Südeingang, die aktualisierte Telefonnummer für Besucher und die Rampe am Fluss enthält.
Bleibe in Terminal, in /home/labex/project/guide-team/editor. Ein Merge führt Verläufe zusammen. Da diese Änderungen verschiedene Dateien betreffen, kann Git ihre Texte automatisch kombinieren. --no-edit übernimmt die von Git erzeugte Merge-Nachricht und verhindert das Öffnen eines Editors:
git merge --no-edit origin/main
Erwarte eine Zusammenfassung des erfolgreichen Merges, üblicherweise Merge made by the 'ort' strategy.. Git erstellt einen Merge-Commit mit zwei direkten Vorgängern: deinem ursprünglichen Commit und dem ursprünglichen Commit des Teammitglieds. Keiner der Beiträge wird umgeschrieben.
Lies die tatsächlich zusammengeführten Dateien:
cat guide.txt
cat access.txt
cat contacts.txt
Der Leitfaden muss South entrance, 09:00-17:00 und den Satz zum letzten Einlass behalten; der Zugangsweg muss Use the riverside ramp lauten; die Telefonnummer muss 010-555-0120 bleiben. Unabhängige Änderungen ließen sich sauber kombinieren, aber ihre Bedeutung musst du weiterhin beurteilen.
Prüfe den entstandenen Verlauf:
git --no-pager log --oneline --graph --all --decorate
Der Merge bei HEAD -> main verbindet beide Beitragslinien. origin/main bezeichnet bis zum Push weiterhin den zuvor abgerufenen Commit des Teammitglieds. Das ist normal: Der Merge hat den lokalen main geändert, nicht den gemeinsamen main.
Prüfe den Arbeitszustand:
git status --short
Es wird keine Ausgabe erwartet. Falls ein anderes Experiment einen laufenden Merge hinterlassen hat, bricht git merge --abort diesen unfertigen Merge ab und stellt den Zustand vor dem Merge wieder her. Führe den Befehl nur während eines laufenden Merges aus und wiederhole danach den Merge-Befehl. Einen bereits abgeschlossenen Commit macht er nicht rückgängig. Der Prüfpunkt verlangt einen zusammengeführten Merge-Commit mit beiden ursprünglichen direkten Vorgängern und allen drei vollständigen Dateien.
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 eine echte Push-Ablehnung bearbeitet, den Commit eines Teammitglieds abgerufen, ohne deine eigenen Dateien zu überschreiben, zwei unabhängige Beiträge zusammengeführt und den vollständigen Leitfaden über ein gemeinsames Repository ausgeliefert. Ein echter empfangender Klon enthielt den kombinierten Leitfaden, den stufenlosen Zugangsweg und den Besucherkontakt.
Die ursprünglichen Commits bleiben im Verlauf erhalten. Als Nächstes übst du einen Merge, bei dem Git dein Urteil benötigt, weil beide Personen dieselbe Zeile geändert haben.
