Kapitel ▾ 2. Auflage

1.1 Erste Schritte - Über Versionskontrolle

Dieses Kapitel befasst sich mit den ersten Schritten mit Git. Wir beginnen mit einer Erklärung von Versionskontrollwerkzeugen, gehen dann dazu über, wie Git auf Ihrem System installiert wird, und schließlich, wie Sie es einrichten, um mit der Arbeit zu beginnen. Am Ende dieses Kapitels sollten Sie verstehen, warum Git existiert, warum Sie es verwenden sollten und wie Sie es dazu einrichten.

Über Versionskontrolle

Was ist „Versionskontrolle“ und warum sollten Sie sich dafür interessieren? Versionskontrolle ist ein System, das Änderungen an einer Datei oder einer Gruppe von Dateien im Laufe der Zeit aufzeichnet, damit Sie bestimmte Versionen später wiederherstellen können. Für die Beispiele in diesem Buch verwenden wir Softwarequellcode als die zu versionierenden Dateien, obwohl Sie dies in Wirklichkeit mit fast jeder Art von Datei auf einem Computer tun können.

Wenn Sie Grafik- oder Webdesigner sind und jede Version eines Bildes oder Layouts behalten möchten (was Sie mit ziemlicher Sicherheit möchten), ist ein Versionskontrollsystem (VCS) sehr ratsam. Es ermöglicht Ihnen, ausgewählte Dateien auf einen früheren Zustand zurückzusetzen, das gesamte Projekt auf einen früheren Zustand zurückzusetzen, Änderungen im Laufe der Zeit zu vergleichen, zu sehen, wer zuletzt etwas geändert hat, das ein Problem verursachen könnte, wer ein Problem eingeführt hat und wann, und vieles mehr. Die Verwendung eines VCS bedeutet im Allgemeinen auch, dass Sie sich leicht erholen können, wenn Sie Dinge vermasseln oder Dateien verlieren. Zusätzlich erhalten Sie all dies mit sehr geringem Aufwand.

Lokale Versionskontrollsysteme

Die bevorzugte Methode zur Versionskontrolle vieler Leute ist das Kopieren von Dateien in ein anderes Verzeichnis (vielleicht ein zeitgestempeltes Verzeichnis, wenn sie clever sind). Dieser Ansatz ist sehr verbreitet, da er sehr einfach ist, aber auch unglaublich fehleranfällig. Es ist leicht zu vergessen, in welchem Verzeichnis Sie sich befinden, und versehentlich in die falsche Datei zu schreiben oder Dateien zu überschreiben, die Sie nicht überschreiben möchten.

Um dieses Problem zu lösen, entwickelten Programmierer vor langer Zeit lokale VCS, die eine einfache Datenbank hatten, die alle Änderungen an Dateien unter Versionskontrolle hielt.

Local version control diagram
Abbildung 1. Diagramm der lokalen Versionskontrolle

Eines der beliebtesten VCS-Tools war ein System namens RCS, das heute noch mit vielen Computern ausgeliefert wird. RCS funktioniert, indem es Patch-Sets (d. h. die Unterschiede zwischen Dateien) in einem speziellen Format auf der Festplatte speichert; es kann dann durch Aufsummieren aller Patches wiederherstellen, wie jede Datei zu jedem Zeitpunkt aussah.

Zentralisierte Versionskontrollsysteme

Das nächste große Problem, auf das die Leute stoßen, ist, dass sie mit Entwicklern auf anderen Systemen zusammenarbeiten müssen. Um dieses Problem zu lösen, wurden zentralisierte Versionskontrollsysteme (CVCS) entwickelt. Diese Systeme (wie CVS, Subversion und Perforce) haben einen einzigen Server, der alle versionierten Dateien enthält, und eine Reihe von Clients, die Dateien von diesem zentralen Ort aus abrufen. Seit vielen Jahren ist dies der Standard für die Versionskontrolle.

Centralized version control diagram
Abbildung 2. Diagramm der zentralisierten Versionskontrolle

Diese Einrichtung bietet viele Vorteile, insbesondere gegenüber lokalen VCS. Zum Beispiel weiß jeder bis zu einem gewissen Grad, was jeder andere im Projekt tut. Administratoren haben eine feingranulare Kontrolle darüber, wer was tun kann, und es ist weitaus einfacher, ein CVCS zu verwalten, als lokale Datenbanken auf jedem Client zu handhaben.

Diese Einrichtung hat jedoch auch einige ernsthafte Nachteile. Der offensichtlichste ist der einzelne Ausfallpunkt, den der zentrale Server darstellt. Wenn dieser Server für eine Stunde ausfällt, kann während dieser Stunde niemand zusammenarbeiten oder versionierte Änderungen an dem speichern, woran er arbeitet. Wenn die Festplatte, auf der sich die zentrale Datenbank befindet, beschädigt wird und keine ordnungsgemäßen Sicherungen geführt wurden, verlieren Sie absolut alles – die gesamte Projekthistorie, mit Ausnahme der einzelnen Schnappschüsse, die Leute zufällig auf ihren lokalen Rechnern haben. Lokale VCS leiden unter demselben Problem – wann immer Sie die gesamte Projekthistorie an einem einzigen Ort haben, riskieren Sie, alles zu verlieren.

Verteilte Versionskontrollsysteme

Hier kommen verteilte Versionskontrollsysteme (DVCS) ins Spiel. In einem DVCS (wie Git, Mercurial oder Darcs) rufen Clients nicht nur den neuesten Schnappschuss der Dateien ab; stattdessen spiegeln sie das Repository vollständig, einschließlich seiner vollständigen Historie. Wenn also ein Server ausfällt und diese Systeme über diesen Server zusammengearbeitet haben, kann jedes der Client-Repositories auf den Server zurückkopiert werden, um ihn wiederherzustellen. Jede Klonung ist wirklich eine vollständige Sicherung aller Daten.

Distributed version control diagram
Abbildung 3. Diagramm der verteilten Versionskontrolle

Darüber hinaus kommen viele dieser Systeme ziemlich gut damit zurecht, mehrere Remote-Repositories zur Verfügung zu haben, mit denen sie arbeiten können, sodass Sie mit verschiedenen Gruppen von Personen auf unterschiedliche Weise gleichzeitig innerhalb desselben Projekts zusammenarbeiten können. Dies ermöglicht Ihnen, mehrere Arten von Workflows einzurichten, die in zentralisierten Systemen nicht möglich sind, wie z. B. hierarchische Modelle.