Erkunden der Versionssteuerung mithilfe von Git

  • 5 Minuten

Es gibt verschiedene Typen von Versionskontrollsystemen (VCS), aber in der Regel können sie als zentralisiert und verteilt kategorisiert werden. In den letzten Jahren (teilweise aufgrund der wachsenden Beliebtheit von DevOps) gewann die letztere Kategorie eine bedeutende Beliebtheit, wobei Git zum de facto Standard in der modernen Softwareentwicklung wird. Diese spezielle VCS wäre die am besten geeignete Wahl für die Organisation in unserem Beispielszenario, insbesondere in Anbetracht der Absicht, GitHub als Zielplattform für den DevOps-Übergang zu verwenden. Erkunden Sie in dieser Lektion die Verwendung von Git als Versionssteuerung.

Screenshot einer Tabelle, in der die Vorteile der zentralen und verteilten Versionssteuerungssysteme verglichen werden.

Zentralisierte vs. verteilte Versionsverwaltung

Sowohl zentrale Versionskontrollessysteme (CVCS) als auch verteilte Versionskontrollessysteme (DVCS) bieten die Möglichkeit, Änderungen in Softwareentwicklungsprojekten zu verwalten und nachzuverfolgen. Die hauptunterschiede zwischen ihnen hängen mit der Art und Weise zusammen, wie Repositorys und Zusammenarbeit implementiert werden. Besonders:

  • Repositoryspeicherort: In zentralisierten Systemen gibt es eine einzige, zentrale Instanz des Repositorys, die den vollständigen Verlauf des Projekts enthält. In verteilten Systemen verfügt jedes Teammitglied in der Regel über eine voll funktionsfähige lokale Kopie des gesamten Repositorys, einschließlich seines Vollversionsverlaufs.
  • Netzwerkkonnektivität: In zentralisierten Systemen ist der Zugriff auf die zentrale Instanz des Repositorys erforderlich, um viele Aktionen auszuführen, einschließlich Updates und Verlaufsabruf. In verteilten Systemen können alle Aktivitäten für die lokale Kopie des Repositorys ausgeführt werden.
  • Kollaboratives Modell: In zentralisierten Systemen checken die Entwickler*innen Dateien aus der zentralen Instanz des Repositorys aus, während sie über ein Netzwerk mit ihr verbunden sind, bevor sie Änderungen vornehmen und die Änderungen festschreiben. Dies verhindert, dass Änderungen an Dateien von anderen ausgecheckt werden. In verteilten Systemen nehmen Entwickler Änderungen an ihrer lokalen Kopie des Repositorys vor, die zu einem späteren Zeitpunkt mit anderen Kopien synchronisiert werden.
  • Verzweigungs- und Zusammenführungsmodell: In zentralisierten Systemen erfordert Verzweigung und Zusammenführung in der Regel die Koordination mit anderen. In verteilten Systemen können Filialen unabhängig in lokalen Kopien erstellt und anschließend zusammengeführt werden.

Es ist erwähnenswert, dass das verteilte Modell zwar nicht auf ein zentrales Repository (im herkömmlichen Sinn) angewiesen ist, es jedoch üblich ist, eine Kopie des Repositorys zu erstellen, die von Diensten wie GitHub, GitLab oder Bitbucket verwaltet wird. Diese Instanz dient als Schwerpunkt der Zusammenarbeit und Synchronisierung.

Screenshot von Repositorien und Zusammenarbeit bei zentralen und verteilten Versionskontrollsystemen.

Git-Terminologie

Um mit Git vertraut zu werden, ist es wichtig, sich mit seiner Terminologie vertraut zu machen. Einige der Konzepte sind für Git einzigartig und unterscheiden sie von anderen DVCS. Zu den grundlegendsten Git-Ausdrücken gehören:

  • Arbeitsstruktur: eine Verzeichnisstruktur, die alle Dateien des Projekts enthält.
  • Repository (allgemein als Repository bezeichnet): das Verzeichnis auf oberster Ebene einer Arbeitsstruktur, das alle Dateien des Projekts zusammen mit dem Versionsverlauf dieser Dateien hosten kann.
  • Klonen: Das Erstellen einer Kopie eines Remoterepository auf einem lokalen Rechner, um an einem Projekt zu arbeiten, auf das Sie Zugriff haben.
  • Fork: die Aktion, eine von GitHub gehostete Kopie eines Remote-Repositories zu erstellen, um an einem Projekt zu arbeiten, auf das Sie keinen Zugriff haben. Ein Fork wird in der Regel verwendet, wenn Sie am Projekt einer anderen Person mitwirken oder Ihre eigene Version eines solchen Projekts erstellen möchten. Während Sie keinen Schreibzugriff auf das ursprüngliche Repository haben, können Sie Ihren Fork vollständig verwalten.
  • Commit: Eine Momentaufnahme der An den Dateien in einem Repository vorgenommenen Änderungen zu einem bestimmten Zeitpunkt. Commits werden verwendet, um Änderungen aufzuzeichnen und zu speichern.
  • Stagingbereich: Ein Zwischenspeicherort (der nicht Teil des Repositorys ist), an dem Änderungen an Dateien in der Arbeitsstruktur vorbereitet werden, bevor sie übertragen werden. Es ermöglicht Entwicklern, Änderungen auszuwählen, die sie übernehmen möchten.
  • Branch: eine benannte Reihe von verknüpften Commits. In einfachen Worten stellt eine Verzweigung eine unterschiedliche Version eines Projekts dar. Dies ermöglicht das gleichzeitige Arbeiten an verschiedenen Teilen eines Projekts, ohne die Hauptversion zu beeinflussen. Der letzte Commit innerhalb eines Branches wird als head bezeichnet. Der Standardzweig, der automatisch generiert wird, wenn Sie ein Repository initialisieren, wird als main oder master genannt.
  • Mergen: Das Zusammenführen von Änderungen aus einem Branch (oder Commit) in einen anderen Branch. Dadurch werden Änderungen von einer Verzweigung in eine andere integriert.
  • Objekt: einer von vier Typen von Entitäten, die in einem Repository verfügbar sind. Zu diesen Entitäten gehören Blobs , die einzelne Dateien darstellen, eine Struktur , die eine Arbeitsstruktur darstellt, ein Commit , der eine bestimmte Version der Arbeitsstruktur darstellt, und ein *-Tag, bei dem es sich um eine Bezeichnung handelt, die einem einzelnen Commit zugewiesen ist.
  • Hash: ein automatisch generierter, eindeutiger Bezeichner mit fester Länge, der den Inhalt eines Objekts darstellt. Jedes Mal, wenn sich das Objekt ändert, ändert sich auch sein Hash. Auf diese Weise kann Git bestimmen, welche Inhalte innerhalb eines Repositorys aktualisiert wurden.
  • Remote: Ein Verweis auf ein anderes Repository (außer dem lokalen Repository), das in der Regel auf die vom Dienst gehostete Instanz des Repositorys verweist. Dies dient als Standard für Push- und Pullvorgänge.
  • Pull: Das Abrufen von Änderungen aus einem Remoterepository und deren Zusammenführung mit dem aktuellen Branch.
  • Push: Das Senden lokaler Commits an ein Rempte-Repository, um es mit den lokal vorgenommenen Änderungen zu aktualisieren.
  • Fetch: Das Abrufen von Änderungen aus einem Remoterepository, ohne sie automatisch zu mergen. Dies ermöglicht ihnen eine Überprüfung, bevor sie einen Merge anwenden.
  • Pull-Request: ein Feature auf Git-basierten Hostingplattformen (z. B. GitHub), mit dem Entwickler Änderungen vorschlagen und deren Zusammenführung in einen Zielzweig anfordern können.

Git verfügt auch über eine umfangreiche Reihe von Befehlen, die die Möglichkeit bieten, die Versionssteuerung vollständig über befehlsshell wie Linux Bash oder Windows-Eingabeaufforderung zu implementieren und zu verwalten. Alternativ können Sie Git über Desktopanwendungen wie GitHub Desktop verwalten. Git-basierte Hostingplattformen bieten eine Webschnittstelle, die die Interaktion mit dienstseitigen Repositorys erleichtert.

Git vs. GitHub

Wie bereits beschrieben, ist Git ein plattformübergreifender Open-Source-DVCS, der die Zusammenarbeit mithilfe lokaler Repositorys erleichtert, die mit Remoterepositorys synchronisiert werden können. GitHub ist ein cloudbasierter Dienst, der eine Hostingplattform für Git-Repositorys bereitstellt. Er erweitert die Bandbreite von Git-Funktionen, indem er Unterstützung für Folgendes einbezieht:

  • Remoterepositorys: Erleichterung der Interaktion zwischen verteilten Teams.
  • Tools für die Zusammenarbeit: Bereitstellung von Features wie Probleme, Diskussionen, Pullanfragen, Benachrichtigungen, Bezeichnungen, Aktionen, Forks, Wikis und Projekte.
  • Webbasierte Schnittstelle: Minimieren der Notwendigkeit der Verwendung von Git-Befehlen
  • Branch-Schutz: Durchsetzung von Bedingungen, die erfüllt werden müssen, bevor ein Merge stattfinden kann (z. B. abgeschlossene Pull-Request-Reviews).