Das gemeinsame Repository klonen

origin.git enthält jetzt denselben Verlauf mit zwei Commits auf main wie garden. Ein Klon macht aus diesem Repository ein neues Arbeitsrepository mit eigenem lokalem Branch, Arbeitsbaum und eigenen Remote-Tracking-Referenzen.

Das Repository klonen

git clone nimmt einen Repository-Speicherort und ein Zielverzeichnis entgegen. Es legt das Ziel an, kopiert den erreichbaren Git-Verlauf, checkt einen Arbeitsbaum aus und trägt die Quelle unter dem üblichen Remote-Namen origin ein.

Der Shell-Befehl cd bedeutet change directory, also Verzeichnis wechseln. cd .. geht eine Ebene hinauf ins Elternverzeichnis. cd garden-copy betritt das genannte Verzeichnis innerhalb des aktuellen. Der Befehl ändert, wo spätere Befehle ausgeführt werden. Er verschiebt keine Dateien und wechselt keine Git-Branches.

Wechsle zuerst von /workspace/garden nach /workspace, damit alle drei Repositories nebeneinanderliegen. Klone dann vom relativen Pfad origin.git nach garden-copy und betrete dieses neue Verzeichnis:

cd ..
git clone origin.git garden-copy
cd garden-copy

Dieser Klon dient in diesem Kapitel zum Beobachten: Du prüfst darin Zustände und führst fetch aus. Jeder neue Commit entsteht aber im vorbereiteten Repository garden.

Den gespeicherten Remote-Speicherort korrigieren

Sieh dir an, was der Klon als origin eingetragen hat. Du findest den vollständigen Pfad /workspace/origin.git, nicht das eingegebene origin.git. Git hat ihn erweitert.

Das solltest du korrigieren. Den dafür nötigen Befehl wirst du später wieder brauchen. Repositories ziehen um: Ein Projekt bekommt einen anderen Platz auf dem Datenträger, eine Serveradresse ändert sich, ein Team wechselt den Host. Dann ist der unter origin gespeicherte Ort schlicht falsch. Mit git remote set-url korrigierst du ihn. Der Befehl nimmt den Namen des Remotes und den neuen Speicherort entgegen.

git remote set-url origin ../origin.git

Jetzt beschreiben beide Repositories origin.git auf dieselbe Weise: als das Nachbarverzeichnis, das es ist. Das hat nur eine gespeicherte Einstellung geändert. Kein Commit wurde verschoben, keine Datei verändert, und der Klon zeigt noch auf dasselbe Bare-Repository wie gerade eben.

Prüfen, was clone angelegt hat

Führe die bereits bekannte ausführliche Remote-Liste aus und lies dann beide Referenzen:

git remote -v
git log main
git log origin/main
git status

git remote -v sollte ../origin.git zeigen. Der lokale main und origin/main beginnen beide beim vorbereiteten Commit List the first plants. Der Arbeitsbaum enthält README.md und plants.txt und ist sauber.

Die Namen gehören lokal zu diesem Klon. Sein main ist nicht der main von garden, und sein origin/main ist keine Live-Ansicht des Bare-Repositorys. Jedes Repository speichert eigene Referenzen. Sie stimmen jetzt überein, weil das Klonen den aktuellen Zustand kopiert hat.

Drei Repositories enthalten jetzt dieselben zwei Commits. Jedes verwaltet seine eigenen Namen dafür. Diese Unabhängigkeit ist der ganze Sinn der Anordnung. Sie bleibt genau so lange unsichtbar, wie alle drei übereinstimmen. In der nächsten Lektion geht eines davon voran.