In diesem Teil wird Git vorgestellt, vereinzelte Funktionen erklärt und was der Unterschied zwischen zentralen und verteilten Versionsverwaltungssystemen ist, dargelegt.
Teil 2 beschäftigt sich mit dem Einrichten und Konfigurieren von Git. Desweiteren werden Tipps und Tricks, Software und meine Konfiguration vorgestellt. Interessante Links sind im letzten Abschnitt beigefügt.
Git ist ein verteiltes Versionsverwaltungssystem, das von Linus Torwalds 2005 ins Leben gerufen wurde. Versionsverwaltungssysteme werden hauptsächlich für Quellcode genutzt, um kollaborativ an einer Software zu arbeiten. Dabei werden die verschiedenen Zustände der Daten festgehalten. Diese Zustände können jederzeit analysiert und wiederhergestellt werden.
Aufbau
Git ist in verschiedene Bereiche aufgeteilt. Es ist wichig, dass man dies verstanden hat.
Stash: In diesem landen alle versteckten Veränderungen.
Workspace: Dies ist der Arbeitsbereich, indem gearbeitet wird.
Index: In diesem werden Kopien von Veränderungen gehalten, die für die nächste Version (Commit) herangezogen werden.
Local Repository: Dies enthält alle Commits und befindet sich auf einem lokalen Speichermedium.
Remote Repository: Dies enthält alle Commits und befindet sich auf einem entfernten Speichermedium, z.B. Webspace.
Ich möchte auf ein Cheatsheet hinweisen, das die Struktur von Git sehr gut darstellt und die dazu passenden Befehle.
Funktionen
Ich setze voraus, dass man weiß, was die folgenden Eigenschaften sind und bewirken:
Weitere Dokumentation findet man im Git ready oder in der unten stehenden Dokumentation im letzten Abschnitt „Weitere Informationen“ im Teil 2.
Stash
Ich möchte noch auf den Stash eingehen, da dieser in anderen VCS nicht vorhanden ist.
Der Stash ist eine Ablage für Änderungen, die im Moment stören. Dies wird zum Beispiel genutzt, wenn der Kunde ein Bug
sofort gefixt haben möchte, dann verstaut man die aktuellen Änderungen, an denen man gerade gearbeitet hat auf dem Stash
und kann somit den Bug fixen. Der Fix wird commitet und ggf. gepusht und danach können die verstauten Änderungen
wieder zurückgeholt werden, sodass man damit weiterarbeiten kann.
Siehe Verstaue deine Änderungen.
GitFS
Jetzt wäre doch die Überlegung wert, ob man nicht das ganze Betriebssystem mit allen persönlichen Daten mit solch einem Versionsverwaltungssystem verwaltet. Das existiert auch schon und nennt sich "GitFS" (Git Filesystem). Allerdings ist dieses noch in einem Beta-Status.
Backup mit Git
Eine weitere Möglichkeit besteht darin, dass man auch Backups mit dem VCS machen kann. Dafür wurde das Programm bup geschrieben. Es befindet sich aber auch wie das vorherige GitFS in einem sehr frühen Entwicklungsstadium, sodass man es mit Vorsicht nutzen sollte. Einer der Entwickler hielt während dem 28C3 im letzten Jahr einen Vortrag darüber, der auch aufgezeichnet wurde: Video in besserer Qualität | Youtube
Verteilt vs. Zentral
Verteilte Versionsverwaltungssysteme (VCS) sind, im Gegensatz zu zentralen Versionsverwaltungssystemen, verteilt. Das
heißt, dass es ein einziges, zentrales Repository gibt, das von allen Teilnehmern genutzt wird. Das heißt aber auch,
dass immer eine Verbindung zu diesem Repository bestehen muss, wenn man Commiten möchte.
Konnektivitätsschwankungen in Verbindung mit zentralen VCS führt kurz- oder langfristig zu unsauberen Repositories.
Ich fahre zum Beispiel auf einer Zugfahrt durch Deutschland und arbeite an einer Software. Ich setze ein zentrales VCS
ein und es gibt immer wieder Verbindungsabbrüche. Da es zu lange dauern würde immer wieder auf Verbindungen zu warten,
arbeite ich einfach weiter und commite erst dann, wenn ich eine Verbindung habe. Das führt zu unsauberen Commits.
Normalerweise werden Commits in Einheiten zusammen gepackt, die eine Veränderung betragen. Zum Beispiel das
Hinzufügen eines Features oder das Fixen eines Bugs. Bei meiner Zugfahrt würden die Commit aber mehrere
Veränderungsblöcke zusammenfassen. Somit ist die Versionsgeschichte sehr unsauber und man kann nicht ohne
Mehraufwand einen älteren Commit auschecken.
Dieser Nachteil besteht bei verteilten oder dezentalisierten Versionsverwaötungssystemen nicht. Jeder Teilnehmer hat
ein eigenes lokales Repository zusätzlich zum zentralen Repository. Damit kann ich, auch bei Verbindungsschwankungen,
saubere Commits auf meinem lokalen Repository durchführen. Irgendwann können diese Commits dem zentralen Repository
mit einem Push zugeführt werden.
Ein weiterer Vorteil davon ist, dass alle Teilnehmer völlig unabhängig von den anderen Teilnehmern arbeiten können. Es
können sogar mehrere Teilnehmer gleichzeitig an einer Datei arbeiten, da diese nur auf den lokalen Kopien Veränderungen
durchführen. Es gibt VCS, die das nicht zulassen: SVN.