Lokale und Remote-Repositorys vergleichen und kontrastieren
Git ist ein verteiltes System, in dem sich der Quellcode auf dem Computer jedes Entwicklers befindet. Dies schließt den vollständigen Verlauf mit allen jemals für dieses Projekt erstellten Commits ein. Dies nennt man ein lokales Repository.
Auf diese Weise kann der Entwickler in seiner eigenen isolierten Umgebung arbeiten, ohne befürchten zu müssen, dass jemand seinen Code beschädigt, während er noch eine Funktion entwickelt. Außerdem können Sie Code mit früheren Versionen, Rollback-Code, Zusammenführungscode usw. vergleichen. Sie können dies sogar ohne Netzwerkverbindung tun.
Die meiste Arbeit von Entwicklern mit Git wird in einem lokalen Repository durchgeführt. Git unterstützt (und erleichtert) die Verzweigung. Die Verzweigung wird in einem separaten Modul behandelt, aber die meisten Verzweigungen werden auch in einem lokalen Repository erstellt.
In einer späteren Phase müssen Sie dem Entwicklungsteam Ihre Änderungen oder neuen Funktionen mitteilen. Daher verwendet Git ein Remote-Repository. Ein lokales Repository kann bei Bedarf auch mit mehreren Remote-Repositorys verknüpft werden. Das Remote-Repository wird verwendet, um Code einfach mit anderen Teammitgliedern zu teilen, aber auch um Buildpipelines einzurichten. Diese Pipelines erstellen den Code, der zum Remote-Repository übertragen wird. Eine Übertragung kann der Trigger zum Starten der Pipeline sein.
Lokales Repository
Im lokalen Repository können drei verschiedene Bereiche oder Verzeichnisse unterschieden werden.
Arbeitsverzeichnis – Dies ist ein einzelnes Auschecken einer Codeversion. Das Arbeitsverzeichnis enthält den Code, mit dem Sie aktiv arbeiten. Sie können die Dateien mithilfe des Befehls Auschecken ändern. Jedes Mal, wenn Sie den aktiven Arbeitszweig ändern, werden die Dateien in Ihrem Arbeitsverzeichnis so geändert, dass sie der spezifischen Version des Codes ähneln. Die Dateien, die Sie in Ihrem Windows Explorer sehen können, sind Dateien im Arbeitsverzeichnis.
Stagingbereich – Dieser Bereich wird als Bereich zwischen Ihrem Arbeitsverzeichnis und dem Git-Verzeichnis verwendet. Bevor Sie eine Datei aus dem Arbeitsverzeichnis in das Git-Verzeichnis übertragen können, müssen Sie die Datei zunächst bereitstellen. Die Datei wird dann unverändert für das nächste Commit markiert. Sie können mit der Datei weiterarbeiten. Alle nicht bereitgestellten Änderungen an dieser Datei werden beim nächsten Commit nicht hinzugefügt. Es wird nur der Inhalt der bereitgestellten Datei hinzugefügt. Dies ist nützlich, wenn Sie an einer Funktion arbeiten, aber noch nicht vollständig fertig sind. Sie können Ihre Änderungen vornehmen und weiterarbeiten. Wenn Sie am Ende des Tages ein Commit durchführen müssen, können Sie dennoch eine Arbeitsversion (die Version aus dem Staging-Bereich) festschreiben, ohne das Risiko, eine halb entwickelte Datei festzuschreiben.
Git-Verzeichnis – Das Git-Verzeichnis enthält alle Metadaten und die Objektdatenbank. Jede Datei, die Sie in das Git-Verzeichnis übertragen, wird in diesem Verzeichnis gespeichert. Wenn Sie Ausgeblendete Elemente im Windows Explorer aktivieren, wird ein ausgeblendeter .git-Ordner angezeigt. Dieser Ordner enthält Unterordner mit den Objekten, aber auch mit Zeigerinformationen. Wenn Sie diesen Ordner löschen, ist Ihr lokales Git-Repository nicht mehr vorhanden. Dies macht es auch einfach, Ihr lokales Repository auf einem USB-Laufwerk zu speichern und mitzunehmen und auf anderen Computern zu verwenden. Seien Sie vorsichtig mit diesem Verzeichnis, sonst wird Ihr lokales Repository nicht mehr nutzbar sein. Dies ist auch das Verzeichnis, das zur Synchronisierung mit dem Remote-Repository verwendet wird.
Mit dieser Einrichtung kann sich eine Datei in Git in einer von drei Phasen befinden.
Nicht geändert und im Git-Verzeichnis gespeichert: Die Datei ist bestätigt.
Geändert und im Staging-Bereich: Die Datei ist bereitgestellt.
Geändert und nicht im Staging-Bereich: Die Datei ist geändert.
Git-Datei-Lebenszyklus
Im nächsten Schema sehen Sie den gesamten Lebenszyklus, den eine Datei durchlaufen kann. Wenn zum ersten Mal eine neue Datei erstellt oder einem Ordner in Ihrem Windows Explorer hinzugefügt wird, erhält die Datei den Status nicht nachverfolgt. Diese Datei ist nicht Bestandteil des Git-Lebenszyklus. Verwenden Sie den Befehl Hinzufügen zum Hinzufügen dieser Datei zum Staging-Bereich, in dem sie bereitgestellt wird. Später können Sie den Befehl commit verwenden, um die Datei zum Git-Verzeichnis hinzuzufügen. Dann erhält die Datei den Status unverändert. Wann immer Sie eine Datei bearbeiten, erhält die Datei den Status geändert oder nicht verfolgt, wenn Sie die Datei aus dem Git-Verzeichnis entfernen. Sie verwenden den rm-Befehl zum Entfernen einer Datei. Das Entfernen einer Datei aus dem Git-Verzeichnis bedeutet nicht, dass die Datei auch auf der Festplatte gelöscht wird. Dies ist eine Aktion, die Sie als Entwickler manuell ausführen müssen.
Remote-Repository
Das Remote-Repository wird dann über die Befehle Push und Pull zum Synchronisieren mit Ihrem lokalen Repository verwendet. Selbst wenn Sie Code freigeben oder Updates von Ihrem Team erhalten, erfolgt dies über Befehle, die Ihr lokales Repository aktualisieren. Da jedes Repository in sich geschlossen ist, ist der Eigentümer des Repositorys dafür verantwortlich, es über Änderungen anderer auf dem Laufenden zu halten.
Im nächsten Schema können Sie sehen, wie zwei Entwickler das Remote-Repository verwenden können, um Änderungen gemeinsam zu nutzen. Entwickler A schreibt Änderungen am lokalen Repository fest und verwendet den Befehl Push zum Hochladen von Änderungen in das Remote-Repository. Entwickler B kann den Befehl Pull zum Herunterladen der Änderungen verwenden und kann Änderungen übertragen.
