1.3 Getting Started - Was ist Git?

Der Hauptunterschied zwischen Git und jedem anderen VCS (einschließlich Subversion und ähnlichen Systemen) liegt in der Art und Weise, wie Git seine Daten betrachtet. Konzeptionell speichern die meisten anderen Systeme Informationen als eine Liste von dateibasierten Änderungen. Diese anderen Systeme (CVS, Subversion, Perforce und so weiter) betrachten die von ihnen gespeicherten Informationen als eine Menge von Dateien und die Änderungen, die im Laufe der Zeit an jeder Datei vorgenommen wurden (dies wird üblicherweise als delta-basierte Versionskontrolle beschrieben).

Git denkt oder speichert seine Daten nicht auf diese Weise. Stattdessen denkt Git über seine Daten eher wie eine Reihe von Schnappschüssen eines Miniatur-Dateisystems. Mit Git nimmt Git jedes Mal, wenn Sie den Zustand Ihres Projekts committen oder speichern, im Grunde ein Bild davon auf, wie alle Ihre Dateien in diesem Moment aussehen, und speichert eine Referenz auf diesen Schnappschuss. Um effizient zu sein, speichert Git eine Datei nicht erneut, wenn sie sich nicht geändert hat, sondern nur einen Link zur vorherigen identischen Datei, die es bereits gespeichert hat. Git denkt über seine Daten eher wie ein Stream von Schnappschüssen.

Dies ist ein wichtiger Unterschied zwischen Git und fast allen anderen VCS. Er veranlasst Git, fast jeden Aspekt der Versionskontrolle neu zu überdenken, den die meisten anderen Systeme von der vorherigen Generation übernommen haben. Das macht Git eher zu einem Mini-Dateisystem mit unglaublich leistungsstarken Werkzeugen, anstatt nur zu einem VCS. Wir werden einige der Vorteile untersuchen, die Sie durch die Betrachtung Ihrer Daten auf diese Weise erzielen, wenn wir uns mit Git-Branching in Git-Branching befassen.

Die meisten Operationen in Git benötigen nur lokale Dateien und Ressourcen für den Betrieb – im Allgemeinen werden keine Informationen von einem anderen Computer in Ihrem Netzwerk benötigt. Wenn Sie an ein CVCS gewöhnt sind, bei dem die meisten Operationen mit Netzwerk-Latenz verbunden sind, wird Sie dieser Aspekt von Git denken lassen, dass die Götter der Geschwindigkeit Git mit überirdischen Kräften gesegnet haben. Da Sie die gesamte Historie des Projekts direkt auf Ihrer lokalen Festplatte haben, scheinen die meisten Operationen fast augenblicklich zu erfolgen.

Um beispielsweise die Historie des Projekts anzuzeigen, muss Git nicht auf den Server gehen, um die Historie abzurufen und anzuzeigen – es liest sie einfach direkt aus Ihrer lokalen Datenbank. Das bedeutet, dass Sie die Projekt-Historie fast sofort sehen. Wenn Sie die Änderungen sehen möchten, die zwischen der aktuellen Version einer Datei und der Datei von vor einem Monat eingeführt wurden, kann Git die Datei von vor einem Monat nachschlagen und eine lokale Differenzberechnung durchführen, anstatt entweder einen Remote-Server damit zu beauftragen oder eine ältere Version der Datei vom Remote-Server abzurufen, um sie lokal zu verarbeiten.

Dies bedeutet auch, dass es sehr wenig gibt, was Sie nicht tun können, wenn Sie offline oder nicht per VPN verbunden sind. Wenn Sie in ein Flugzeug oder einen Zug steigen und ein wenig arbeiten möchten, können Sie glücklich committen (in Ihre lokale Kopie, erinnern Sie sich?) bis Sie eine Netzwerkverbindung haben, um hochzuladen. Wenn Sie nach Hause gehen und Ihr VPN-Client nicht richtig funktioniert, können Sie trotzdem arbeiten. In vielen anderen Systemen ist dies entweder unmöglich oder mühsam. In Perforce zum Beispiel können Sie nicht viel tun, wenn Sie nicht mit dem Server verbunden sind; in Subversion und CVS können Sie Dateien bearbeiten, aber Sie können keine Änderungen in Ihrer Datenbank committen (weil Ihre Datenbank offline ist). Dies scheint vielleicht keine große Sache zu sein, aber Sie werden überrascht sein, wie viel Unterschied es machen kann.

Alles in Git wird vor der Speicherung per Checksumme überprüft und dann über diese Checksumme referenziert. Das bedeutet, dass es unmöglich ist, den Inhalt einer Datei oder eines Verzeichnisses zu ändern, ohne dass Git davon Kenntnis erhält. Diese Funktionalität ist in Git auf den untersten Ebenen integriert und integraler Bestandteil seiner Philosophie. Sie können keine Informationen während der Übertragung verlieren oder Dateikorruption erleiden, ohne dass Git dies erkennen kann.

Der Mechanismus, den Git für diese Checksummen verwendet, wird als SHA-1-Hash bezeichnet. Dies ist eine 40-stellige Zeichenkette, die aus hexadezimalen Zeichen (0-9 und a-f) besteht und basierend auf dem Inhalt einer Datei oder Verzeichnisstruktur in Git berechnet wird. Ein SHA-1-Hash sieht ungefähr so aus

Sie werden diese Hash-Werte überall in Git sehen, weil es sie so häufig verwendet. Tatsächlich speichert Git alles in seiner Datenbank nicht nach Dateinamen, sondern nach dem Hash-Wert seines Inhalts.

Wenn Sie Aktionen in Git durchführen, fügen fast alle davon nur Daten zur Git-Datenbank hinzu. Es ist schwierig, das System dazu zu bringen, etwas zu tun, das nicht rückgängig gemacht werden kann, oder es dazu zu bringen, Daten auf irgendeine Weise zu löschen. Wie bei jedem VCS können Sie Änderungen verlieren oder vermasseln, die Sie noch nicht committet haben, aber nachdem Sie einen Schnappschuss in Git committet haben, ist es sehr schwierig, ihn zu verlieren, besonders wenn Sie Ihre Datenbank regelmäßig in ein anderes Repository pushen.

Das macht die Nutzung von Git zu einer Freude, denn wir wissen, dass wir experimentieren können, ohne die Gefahr, etwas ernsthaft zu vermasseln. Für einen detaillierteren Einblick, wie Git seine Daten speichert und wie Sie scheinbar verlorene Daten wiederherstellen können, siehe Dinge rückgängig machen.

Achten Sie jetzt aufmerksam hin – dies ist das Wichtigste, das Sie sich über Git merken sollten, wenn Sie möchten, dass der Rest Ihres Lernprozesses reibungslos verläuft. Git hat drei Hauptzustände, in denen sich Ihre Dateien befinden können: modifiziert, gestaged und committet

Dies führt uns zu den drei Hauptbereichen eines Git-Projekts: dem Arbeitsverzeichnis, dem Staging-Bereich und dem Git-Verzeichnis.

Das Arbeitsverzeichnis ist ein einzelner Checkout einer Version des Projekts. Diese Dateien werden aus der komprimierten Datenbank im Git-Verzeichnis extrahiert und auf die Festplatte gelegt, damit Sie sie verwenden oder ändern können.

Der Staging-Bereich ist eine Datei, die im Allgemeinen in Ihrem Git-Verzeichnis enthalten ist und Informationen darüber speichert, was in Ihren nächsten Commit aufgenommen wird. Sein technischer Name im Git-Jargon ist "Index", aber die Phrase "Staging-Bereich" funktioniert genauso gut.

Das Git-Verzeichnis ist der Ort, an dem Git die Metadaten und die Objektdatenbank für Ihr Projekt speichert. Dies ist der wichtigste Teil von Git und wird kopiert, wenn Sie ein Repository von einem anderen Computer klonen.

Der grundlegende Git-Workflow sieht ungefähr so aus

Wenn eine bestimmte Version einer Datei im Git-Verzeichnis vorhanden ist, gilt sie als committet. Wenn sie modifiziert und zum Staging-Bereich hinzugefügt wurde, ist sie gestaged. Und wenn sie geändert wurde, seit sie ausgecheckt wurde, aber nicht gestaged wurde, ist sie modifiziert. In Git-Grundlagen lernen Sie mehr über diese Zustände und wie Sie diese nutzen oder den gestagten Teil ganz überspringen können.