Mit Fetch abrufen, ohne Main zu verschieben

Alle drei Repositories stimmen derzeit überein. Um die Wirkung von fetch zu sehen, erstellst du einen weiteren Commit in garden, pushst ihn in das Bare-Repository und rufst ihn mit fetch in garden-copy ab. Es gibt nur einen Schreibenden. Die Verläufe laufen deshalb nicht auseinander.

Garden und sein Origin voranbringen

Wechsle von garden-copy zurück zum vorbereiteten Repository garden und öffne in nano eine neue Liefernotiz:

cd ../garden
nano -w delivery.txt

Gib diese eine Zeile ein, speichere mit Ctrl-O und Enter und verlasse nano dann mit Ctrl-X:

Seed delivery: Friday

Stelle die gespeicherte Notiz mit den bekannten Befehlen bereit und committe sie:

git add delivery.txt
git commit -m "Record the seed delivery"

Der lokale main von garden hat jetzt einen Commit, den die anderen Repositories noch nicht haben. In Lektion 3 hat -u einen Upstream für diesen Branch eingetragen. Weil diese Beziehung Remote und Branch bereits vorgibt, genügt jetzt ein einfaches git push:

git push

Der Push verschiebt main in origin.git auf den neuen Commit. Außerdem aktualisiert er die eigene Aufzeichnung origin/main von garden. garden-copy hat seit dem Klonen keine Informationen ausgetauscht. Seine beiden Referenzen stehen deshalb noch beim vorbereiteten Commit.

In den Klon abrufen

git fetch kontaktiert ein eingerichtetes Remote, lädt Commits und andere Objekte herunter, die dem aktuellen Repository fehlen, und aktualisiert die entsprechenden Remote-Tracking-Referenzen. Es verschiebt deinen lokalen Branch nicht und verändert die ausgecheckten Dateien nicht.

Wechsle zurück zum Klon und rufe von seinem standardmäßigen Remote origin ab:

cd ../garden-copy
git fetch

Das Wort „kontaktiert“ setzt hier kein Netzwerk voraus. garden-copy liest das benachbarte Repository ../origin.git direkt vom Datenträger.

Den lokalen main mit origin/main vergleichen

Lies zuerst den Verlauf der Remote-Tracking-Referenz, dann den des lokalen Branchs:

git log origin/main
git log main
git status

origin/main enthält jetzt delivery.txt, weil fetch die Aufzeichnung des Remote-Branchs im Klon aktualisiert hat. Der lokale main endet noch beim vorbereiteten Commit List the first plants. Auch der Arbeitsbaum des Klons enthält weiterhin nur README.md und plants.txt und ist sauber.

Dieser Unterschied ist die bleibende Erkenntnis:

garden main ---------> new delivery commit
origin.git main -----> new delivery commit
garden-copy origin/main -> new delivery commit
garden-copy main ----> seeded List the first plants commit

Fetch hat Informationen in den Klon gebracht, ohne zu entscheiden, was mit seinem lokalen Branch geschehen soll. Arbeit nach einem Fetch zusammenzuführen oder vorzuschieben, gehört ins nächste Kapitel.

Der Abstand zwischen origin/main und main im Klon ist kein Fehler, den du schnell korrigieren musst. Git hält damit absichtlich zwei Tatsachen auseinander: was das andere Repository beim letzten Nachsehen enthielt und was du damit tun möchtest. Diese Trennung ermöglicht dir, erst nachzusehen und dann zu handeln.

In Kapitel 8 entscheidest du, was damit geschehen soll. Dort wird es auf genau die Weise schwieriger, die dieses Kapitel vermieden hat: Beide Seiten haben sich bewegt.