»Das ist Git. Es bietet einen Überblick über die kollaborative Arbeit in Projekten durch die Nutzung eines wunderschönen Graphen-Theorie-Modells.«
Sie: »Cool. Aber wir nutzt man es?«
Er: »Keine Ahnung. Merke dir einfach all diese Befehle und tippe sie ein. Wenn du auf Fehler stößt, dann sichere deine Arbeit woanders, lösche das Projekt und lade eine frische Kopie herunter.«
»If that doesn’t fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of ›It’s really pretty simple, just think of branches as...‹ and eventually you’ll learn the commands that will fix everything.«
»Und wenn das auch nicht hilft, dann enthält git.txt die Telefonnummer von einem Freund, der sich mit Git auskennt. Warte einfach ein paar Minuten ab à la ›Es ist wirklich gar nicht so schwer, stell dir nur die Branches vor als ...‹, und schließlich lernst du die Befehle, die jedes Problem fixen.«[1]
Versionskontrolle ist ein wichtiges Thema für Software-Entwickler. Jeder, der ohne jegliche Versionskontrollprogramme arbeitet, ist vermutlich schon einmal an den Punkt gestoßen, wo man sich ältere Stände ansehen wollte. Dabei fragt man sich gegebenenfalls, warum und wann man eine Funktion eingeführt hat, oder man möchte auf einen älteren Stand zurückspringen, wenn man etwas kaputt gemacht hat. Genau an dieser Stelle kommen Versionsverwaltungsprogramme ins Spiel. Git ist eines dieser Programme, die nicht nur die bereits genannten Probleme lösen. Es ist Kernbestandteil des Entwicklungsprozesses, um sowohl kollaborativ im Team als auch alleine an einem Projekt zu arbeiten. Dabei ist es gleichgültig, ob man programmiert, Systeme administriert oder gar Bücher schreibt ist.
Randall Munroe beleuchtet in seinem Webcomic xkcd viele verschiedene Themen. Das hier abgedruckte xkcd-Comic zum Thema Git wurde während meiner Arbeit an der ersten Auflage dieses Buches veröffentlicht. Viele meiner Freunde und Bekannten aus dem Open-Source-Umfeld posteten das Comic in den verschiedenen sozialen Netzwerken und machten eins deutlich: Viele Leute nutzen zwar Git, wissen aber nur grob, was dort passiert. Wenn etwas nicht wie geplant funktioniert oder man zu einem fehlerhaften Zustand im Arbeitsprojekt kommt, dann weiß man erst mal nicht weiter und fragt seinen persönlichen Git-Experten, wie den einen Kollegen, der glücklicherweise ein Git-Buch geschrieben hat.
Das Ziel dieses Buches ist nicht nur, dass Sie die gängigen Befehle erlernen, die Sie beim Arbeiten mit Git brauchen. Ich lege auch großen Wert auf die Einbindung und Anpassung des Entwicklungsprozesses. Darüber hinaus sollten Sie Git als Ganzes verstehen und nicht nur die Grundlagen, damit Sie mit einem Programm arbeiten, das Sie verstehen und bei dem bei Konflikten keine Hürden vorhanden sind.
Dieses Buch besteht aus insgesamt dreizehn Kapiteln, davon gehören die ersten vier Kapitel zu den Grundlagen und die übrigen acht zu den fortgeschrittenen Themen.
Das erste Kapitel führt in das Thema der Versionsverwaltung mit Git ein, um den Einsatzzweck und die Vorteile von Git zu verdeutlichen. Das zweite Kapitel behandelt die grundlegenden Git-Kommandos. Dies beinhaltet die Basis-Befehle, die für das Arbeiten mit Git notwendig sind. Im anschließenden dritten Kapitel geht es um die Nutzung von Branches, eines der elementaren Features von Git. So lernen Sie, mit Branches parallele Entwicklungslinien zu erstellen, zwischen diesen verschiedenen Branches hin und her zu wechseln und sie wieder zusammenzuführen. Der Grundlagenteil endet mit dem vierten Kapitel, bei dem es um den Einsatz von verteilten Repositorys geht, die es ermöglichen, mit Repositorys zu arbeiten, die auf entfernten Servern, wie etwa GitHub oder GitLab, liegen.
Bei den fortgeschrittenen Themen liegt der Fokus besonders auf dem Einsatz von Git in Software-Entwicklungsteams. Wichtig ist dabei, über eine gute Möglichkeit zu verfügen, Git-Repositorys hosten zu können, damit man kollaborativ in einem Team an Projekten arbeiten kann. Während die wohl gängigste, bekannteste und einfachste Hosting-Möglichkeit GitHub ist, gibt es auch einige Open-Source-Alternativen, wie zum Beispiel GitLab, die sich ebenfalls sehr gut für den Einsatz in Firmen oder anderen Projektgruppen eignen. Das ist das Thema im fünften Kapitel, in dem auch der Workflow bei GitHub und GitLab thematisiert wird. Im anschließenden sechsten Kapitel geht es um die verschiedenen existierenden Workflows. Um die Features von Git sinnvoll einzusetzen, sollten Sie einen Workflow nutzen, der sowohl praktikabel ist als auch nicht zu viel Overhead im Projekt führt. Die Art und Weise, mit Git zu arbeiten, unterscheidet sich vor allem bei der Anzahl der Personen, Branches und Repositorys. Im sechsten Kapitel geht es im Anschluss darum, Git-Hooks zu verwenden, um mehr aus dem Projekt herauszuholen oder simple Fehler automatisiert zu überprüfen und somit zu vermeiden. So lernen Sie, was Hooks sind, wie sie programmiert werden und damit zu automatisieren. Generell ist dieses Kapitel für den Git-Nutzer kein alltägliches Thema. Hooks werden im Alltag eher unregelmäßig programmiert.
Die weiteren drei Kapitel befassen sich mit dem Umstieg von Subversion nach Git, wobei sowohl die Übernahme des Quellcodes inklusive der Historie als auch die Anpassung des Workflows thematisiert wird. Das neunte Kapitel ist eine Sammlung vieler verschiedener nützlicher Tipps, die zwar nicht zwangsläufig täglich gebraucht werden, aber trotzdem sehr nützlich sein können. Im zehnten Kapitel folgt dann noch ein Kapitel mit einem Überblick über die grafischen Git-Programme unter den verschiedenen Betriebssystemen Windows, macOS und Linux. In der zweiten Auflage sind die vergleichsweise kurzen Kapitel 11 und 13 neu dazugekommen. Hier werden zum einen nützliche Hilfestellungen gegeben, um eine möglichst nachvollziehbare Git-Historie zu erzeugen, und zum anderen werden häufige Probleme von Anfängern und Erfahrenen beleuchtet und die dazugehörigen Lösungen aufgezeigt. Neu in der dritten Auflage ist das 12. Kapitel. Hier wird das Thema DevOps kurz und kompakt zusammengefasst, wofür Git das grundlegende Werkzeug ist.
Um den Einsatz von Git und die einzelnen Funktionen sinnvoll nachvollziehen zu können, werden alle Git-Kommandos anhand eines realen Beispiels erläutert. Über die Kapitel des Buches hinweg entsteht eine kleine statische Webseite, an der die Funktionen verdeutlicht werden. Denn was bringt es, die Kommandos von Git ohne den Bezug zu realen Projekten und dessen Einsatzzwecke zu kennen? Eine kleine Webseite hat insbesondere den Vorteil, dass Sie nicht nur Unterschiede im Quellcode nachvollziehen, sondern auch sehr einfach die optischen Unterschiede auf einer Webseite erkennen können.
In diesem Buch finden Sie zahlreiche Terminal-Ausgaben abgedruckt. Diese sind größtenteils vollständig, einige mussten aus Platz- und Relevanz-Gründen jedoch gekürzt werden. Eingaben in der Kommandozeile fangen immer mit dem »$« an. Dahinter folgt dann der eigentliche Befehl. Das Dollarzeichen ist der Prompt, der in der Shell dargestellt wird, und muss daher nicht eingetippt werden. Zeilen, die kein solches Zeichen besitzen, sind Ausgaben der Befehle. Das sieht dann etwa so aus:
$ git log commit 9534d7866972d07c97ad284ba38fe84893376e20 [...]
Zeilen, die nicht relevant sind oder verkürzt wurden, sind als »[...]« dargestellt.
Die einzelnen Kapitel bauen zwar aufeinander auf, doch ist es nicht immer möglich, alle Themen an Ort und Stelle ausführlich zu behandeln. Zudem werden wohl eher wenige Leser das Buch von vorne bis hinten durcharbeiten. Das Buch beinhaltet daher einige Hinweise und Tipps. Teilweise sind es Hinweise auf nähere Details in anderen Teilen des Buches, teilweise Tipps und Warnungen für die Nutzung von Git. Dies sind häufig nützliche Inhalte, die sich auf das gerade behandelte Thema beziehen, hin und wieder aber auch Querverweise zu näheren Erläuterungen in anderen Kapiteln.
Als Autor habe ich sehr wohl den Anspruch, dass Sie als Leser das, was in diesem Buch behandelt wird, sowohl richtig verstehen als auch anwenden können. Ich bin daher offen für Feedback und Verbesserungsvorschläge – entweder per E-Mail an mail@svij.org oder Kurzes gerne auch via Twitter an @svijee (https://twitter.com/svijee). Ich bin sehr an Ihrem Feedback interessiert!
Ich freue mich, dass ich erneut die Möglichkeit vom Verlag erhalten habe, dieses Buch in der nun dritten aktualisierten Auflage veröffentlichen zu dürfen. Mein Dank gilt daher erneut dem Verlag mitp und insbesondere meiner Lektorin Sabine, mit der ich nun mittlerweile fünf Jahre an diesem Buch zusammenarbeite.
Weiterhin gilt mein Dank auch dieses Mal meiner Familie und allen, die mir immer wieder neuen kleinen und großen Input und Feedback liefern.
[1] »xkcd: Git«, Copyright Randall Munroe (https://xkcd.com/1597/) ist lizenziert unter der Creative Commons Lizenz CC BY-NC 2.5 (https://creativecommons.org/licenses/by-nc/2.5/)
Versionsverwaltung – Was ist denn nun eigentlich genau ein Versionsverwaltungsprogramm? Wodurch zeichnet es sich aus und warum wird es gebraucht? Das sind einige der häufigen ersten Fragen, die zu Beginn aufkommen. Die prinzipielle Bedeutung leitet sich schon aus dem Wort selbst ab: Es handelt sich um die Verwaltung von Versionen. Konkret bedeutet es, dass Sie von Dateien Versionen erzeugen können, die dann sinnvoll verwaltet werden.
Das Wort »Version« klingt zunächst erst einmal nach einer größeren Änderung, doch auch eine kleine Änderung erzeugt eine neue Version einer Datei. Je nach Kontext gibt es ein unterschiedliches Verständnis für den Begriff »Version«. Wenn bei Git von Versionen gesprochen wird, ist damit so gut wie immer die Version einer einzelnen Datei oder einer Sammlung von Dateien gemeint. Im Sinne der Software-Entwicklung werden neue Versionen von Programmen veröffentlicht, also zum Beispiel die Git-Version 2.29.
Aber wofür brauchen Sie nun ein Versionsverwaltungsprogramm wie Git? Viele kennen vermutlich folgendes Problem: Sie gehen einer Tätigkeit nach – sei es das Schreiben an einem Text, das Bearbeiten eines Bildes oder eines Videos – und der aktuelle Stand soll immer mal wieder zwischengespeichert werden. Hauptgrund ist, dass dauernd eine Sicherung der Datei vorhanden sein soll, und ein weiterer Grund ist, dass Sie wieder auf einen älteren Stand zurückspringen können, falls Sie doch einige Schritte rückgängig machen wollen. Die Vorgehensweise zum manuellen Erzeugen solcher Versionen ist unterschiedlich – die einen fügen Zahlen mit Versionsnummern am Ende des Dateinamens an, die anderen erzeugen wiederum Ordner mit dem aktuellen Datum, in denen die Dateien liegen. So passiert es häufiger, dass neben Bachelorarbeit_v1.odt und Bachelorarbeit_v2.odt noch ein Bachelorarbeit_v3_final.odt und Bachelorarbeit_v3_final_new.odt liegt. Beide genannten Möglichkeiten funktionieren zwar prinzipiell, sind allerdings weder praktikabel noch wirklich sicher und vor allem fehleranfällig. Das ist besonders dann der Fall, wenn Sie den Dateien keine eindeutigen Namen gegeben haben. Dies trifft insbesondere dann zu, wenn zu viele Versionen einer einzigen Datei rumliegen oder mehrere Dateien gleichzeitig versioniert werden müssen.
Genau bei diesem Problem kommen Versionsverwaltungsprogramme zum Einsatz. Mit diesen werden neben den reinen Veränderungen noch weitere Informationen zu einer Version gespeichert. Darunter fallen in der Regel der Autorenname, die Uhrzeit der Änderung und eine Änderungsnotiz. Diese werden bei jeder neuen Version gespeichert. Durch die gesammelten Daten können Sie so schnell und einfach eine Änderungshistorie ansehen und verwalten. Falls zwischendurch Fehler in den versionierten Dateien eingeflossen sind, können Sie leicht untersuchen, wann und durch welche Person die Fehler eingeführt wurden, und diese wieder rückgängig machen. Versionsverwaltungsprogramme lassen sich demnach nicht nur von einzelnen Personen nutzen, sondern ermöglichen das Arbeiten im Team mit mehr als einer Person.
Mit Versionsverwaltungsprogrammen lassen sich alle möglichen Dateitypen verwalten. Sie sollten allerdings beachten, dass eine Versionierung nicht für jeden Dateityp praktikabel ist. Besonders hilfreich sind solche Anwendungen vor allem für Arbeiten mit reinen Text-Dateien. Darunter fallen insbesondere Quellcode von Programmen, Konfigurationsdateien oder auch Texte und somit auch Bücher. Der Vorteil bei reinen Textdateien ist, dass Sie die Unterschiede bei Änderungen für jede Zeile nachvollziehen können – das ist bei binären Dateiformaten nicht möglich. Auch für Grafiker kann der Einsatz eines Versionsverwaltungsprogramms sinnvoll sein, denn mit zusätzlichen Tools können auch die Veränderungen zwischen zwei Versionen von Bildern dargestellt werden.
Insgesamt gibt es drei verschiedene Konzepte zur Versionsverwaltung: die lokale, die zentrale und die verteilte Versionsverwaltung.
Abb. 1.1: Lokale Versionsverwaltung arbeitet Datei-basiert und lediglich lokal.
Die lokale Versionsverwaltung findet sich eher seltener in produktiven Umgebungen, da sie lediglich lokal arbeitet und häufig nur einzelne Dateien versioniert. Die zuvor erwähnte manuelle Erzeugung von Versionen von Dateien wäre zum Beispiel eine lokale Versionsverwaltung mit einer einzelnen Datei. Sie ist zwar einfach zu nutzen, doch ist es fehleranfällig und wenig flexibel. Echte Versionsverwaltungssoftware, die nur lokal arbeitet, gibt es allerdings auch, darunter »SCSS« und »RCS«. Der größte Nachteil lokaler Versionsverwaltung ist, dass im Normalfall nur eine Person mit den Dateien arbeiten kann, da diese nur lokal auf dem einen Gerät verfügbar sind. Weiterhin besteht keine Datensicherheit, da die Dateien nicht automatisch auf einem anderen Gerät gesichert werden. Der Anwender ist somit allein verantwortlich für ein Backup der Dateien inklusive der Versionshistorie.
Abb. 1.2: Zentrale Versionsverwaltung arbeitet mit Arbeitskopien auf Clients.
Zentrale Versionsverwaltungen befinden sich heute vergleichsweise noch häufig im Einsatz. Bekannte und verbreitete Vertreter dieser Art sind Subversion und CVS. Das Hauptmerkmal zentraler Versionsverwaltungen ist, dass das Repository lediglich auf einem zentralen Server liegt. Das Wort »Repository« ist Englisch und steht für »Lager«, »Depot« oder auch »Quelle«. Ein Repository ist somit ein Lager, in dem die versionierten Dateien liegen. Autorisierte Nutzer verfügen über eine lokale Arbeitskopie einer Version, auf der sie ihre Arbeiten erledigen.
Die Logik und die Daten der Versionsverwaltung liegen größtenteils auf dem zentralen Server. Beim Wechsel von Revisionen oder beim Vergleichen von Änderungen wird stets mit dem Server kommuniziert. Wenn der Server also offline ist, kann der Nutzer zwar mit der Arbeitskopie ein wenig weiterarbeiten. Allerdings ist die Einsicht älterer Versionen oder das Ansehen anderer Entwicklungslinien nicht möglich, da es sich lediglich um eine Arbeitskopie einer Version und keine Kopie des vollständigen Repositorys handelt.
Abb. 1.3: Verteilte Versionsverwaltung arbeitet mit Repositorys auf Clients und Servern.
Git gehört zu den verteilt arbeitenden Versionsverwaltungsprogrammen. Neben Git gibt es auch andere verteilte Versionskontrollprogramme, wie Bazaar oder Mercurial. Im Gegensatz zur zentralen Versionsverwaltung besitzt jeder Nutzer des Repositorys nicht nur eine Arbeitskopie, sondern das komplette Repository. Wenn Sie also zwischen verschiedenen Revisionen wechseln oder sich die Historie einzelner Dateien anschauen möchte, dann geschieht das Ganze auf dem lokalen Rechner. Zuvor muss nur das Repository »geklont« werden. Alle Funktionen stehen dann auch offline zur Verfügung. Ein wesentlicher Vorteil davon ist, dass nicht nur unnötiger Datenverkehr vermieden wird, sondern auch die Geschwindigkeit deutlich höher ist, was durch die fehlende Netzwerklatenz bedingt ist.
Zusätzlich besitzen verteilte Versionsverwaltungssysteme eine höhere Datenausfallsicherheit, da die Kopien der Daten des Repositorys in der Regel auf verschiedenen Rechnern liegen. Bei einem Ausfall des Git-Servers ist es daher möglich, weiterzuarbeiten. Nichtsdestotrotz sollten Sie von wichtigen Daten natürlich immer Backups anfertigen, ganz egal ob es sich um lokale, zentrale oder verteilte Versionsverwaltung handelt.
Abb. 1.4: Die Versionshistorie liegt sowohl lokal auf dem Client als auch auf dem Server.
Um den Unterschied zwischen zentralen und verteilten Versionsverwaltungsprogrammen klarer zu machen, kann folgendes Beispiel helfen. Stellen Sie sich vor, dass das Repository ein dicker Aktenordner ist. Darin enthalten sind alle aktuellen Dateien, ältere Versionen der Dateien sowie die Änderungshistorie mitsamt den Kommentaren zu den Änderungen. Sie müssen mit diesen Dateien arbeiten. Wenn es sich um ein zentrales System handelt, dann befindet sich der Aktenordner an einer zentral zugänglichen Stelle, die hier nun Archiv genannt wird. Für Sie heißt es, dass Sie zum Archiv und zu dem Ordner gehen müssen. Dort wird dann eine Arbeitskopie der benötigten Dateien erzeugt und anschließend laufen Sie wieder zurück zum Arbeitsplatz. Wenn Sie die Änderungshistorie von einer oder mehreren Dateien ansehen möchten, müssen Sie immer wieder zum Archiv laufen und den Aktenordner durchblättern, um sich diese anzusehen. Da es sowohl Zeit als auch Energie kostet, immer zum zentralen Aktenordner zu laufen, bietet es sich an, eine Kopie des ganzen Ordners zu erstellen und mit an Ihren Arbeitsplatz zu nehmen.
Genau das ist dann eine verteilte Versionsverwaltung, da nun zwei vollständige Kopien des Aktenordners existieren – einmal an zentraler Stelle im Archiv und einmal am eigenen Arbeitsplatz. Der Vorteil ist, dass nach der ersten Kopie nur noch die Veränderungen hin- und hergetragen werden müssen. Alles andere kann bequem vom Arbeitsplatz aus gemacht werden, ohne ständig aufzustehen und herumlaufen zu müssen. Konkret bedeutet das, dass Sie an Ihrem Arbeitsplatz sitzen und Ihre Aufgaben erledigen. Sobald die Arbeit abgeschlossen ist, tragen Sie nur die neuen Dateien zum Archiv, wo Sie eine Kopie anfertigen und diese im zentralen Aktenordner abheften. Großer Vorteil ist, dass Sie auch weiterhin arbeiten können, wenn der Weg zum Aktenordner unzugänglich ist, etwa genau dann, wenn Sie unterwegs sind.
Zusammenfassung
Die lokale Versionsverwaltung funktioniert lediglich auf einem einzelnen Rechner.
Bei der zentralen Versionsverwaltung liegt das »Gehirn« auf einem zentralen Server, von dem sich alle Mitarbeiter eine Arbeitskopie ziehen können.
Bei der verteilten Versionsverwaltung liegt das vollständige Repository sowohl auf mindestens einem Server sowie auf allen Clients, wo mit Klonen gearbeitet wird.
Seinen Ursprung hatte Git bei der Entwicklung des Linux-Kernels. Letzterer wurde lange Zeit mit BitKeeper verwaltet, das damals ein proprietäres Programm war. Nachdem die Hersteller von BitKeeper die Lizenz geändert hatten, konnten die Linux-Kernel-Entwickler um Linus Torvalds BitKeeper nicht mehr kostenfrei verwenden, weswegen Linus Torvalds mit der Entwicklung von Git begann. Erst im Mai 2016 wurde BitKeeper unter einer Open-Source-Lizenz veröffentlicht.
Die Entwicklung von Git begann im Jahr 2005 und es gehört somit zu den jüngeren Versionsverwaltungssystemen und das, obwohl es mittlerweile mehr als 15 Jahre alt ist. Linus Torvalds fand es wichtig, dass das zukünftig eingesetzte Programm zur Entwicklung des Linux-Kernels drei spezielle Eigenschaften besitzt. Das sind zum Ersten Arbeitsabläufe, die an BitKeeper angelehnt sind, zum Zweiten die Sicherheit gegen böswillige und unbeabsichtigte Verfälschung des Repositorys sowie zum Dritten eine hohe Effizienz. Das Projekt »Monotone« wäre nahezu perfekt für diese Aufgabe gewesen. Das einzige Problem war nur, dass es nicht sonderlich effizient arbeitete. Letztendlich entschied sich Linus Torvalds für die Entwicklung eines komplett neuen Programms, was er dann Git nannte.
Interessant ist auch die Namensgebung von Git. Das Wort »Git« ist das englische Wort für »Blödmann«. Linus Torvalds selbst sagte spaßeshalber: »I’m an egoistical bastard, and I name all my projects after myself. First ›Linux‹, now ›Git‹.« (Deutsch: »Ich bin ein egoistisches Arschloch und ich benenne alle meine Projekte nach mir selbst. Erst ›Linux‹ und jetzt eben ›Git‹.«). Natürlich gab es auch echte Gründe, das Projekt »Git« zu taufen. Zum einen enthält das Wort lediglich drei Buchstaben, was das regelmäßige Tippen auf der Tastatur erleichtert, zum anderen gab es kein bestehendes UNIX-Kommando, mit dem es kollidieren würde.
In diesem Kapitel lernen Sie die grundlegenden Funktionen und Kommandos von Git kennen. So gut wie alle in diesem Kapitel behandelten Befehle dürften beim täglichen Arbeiten mit Git zum Einsatz kommen. Damit Sie den Sinn und Zweck einzelner Befehle und Funktionen von Git sowohl nutzen als auch nachvollziehen können, arbeiten Sie in diesem Kapitel hauptsächlich an einem Beispielprojekt, das die Nutzung und Arbeitsweise von und mit Git verdeutlicht.
Das Beispiel-Projekt ist eine kleine Website, die nach und nach aufgebaut wird. HTML-Kenntnisse sind prinzipiell nicht notwendig, können aber natürlich auch nicht schaden. Damit es nicht ganz so trocken und langweilig ist, sollten Sie die Beispiele auf dem eigenen Rechner auf jeden Fall nachmachen. An der ein oder anderen Stelle bietet es sich auch an, etwas herumzuexperimentieren, denn nur durch Praxis wird Ihnen das Arbeiten mit Git klar und Sie haben hinterher in echten Projekten keine großen Probleme.
Als Beispiel wird eine kleine persönliche Website mit dem HTML5-Framework »Bootstrap« erstellt. Auf die genaue Funktionsweise des Frameworks gehe ich nicht näher ein, da es sich hier ja um Git und nicht um HTML und CSS dreht.
Git ist traditionell ein Kommandozeilenprogramm, weshalb der Fokus auf der Arbeit mit Git in der Kommandozeile liegt. Einschübe mit grafischen Git-Programmen gibt es dennoch. Grafischen Git-Programmen ist mit Kapitel 10, »Grafische Clients« ein vollständiges Kapitel gewidmet.
Bevor Sie losgelegen, müssen Sie Git installieren. Git gibt es nicht nur für die gängigen Betriebssysteme Windows, macOS und Linux, sondern unter anderem auch für FreeBSD, Solaris und sogar Haiku. Die gängigen Linux-Distributionen stellen Git unter dem Paketnamen »git« in der Paketverwaltung zur Verfügung. Nutzer von Windows und mac OS können sich Git von der Projektwebsite https://git-scm.com/downloads herunterladen.
Während der Arbeit an diesem Buch ist die Git-Version 2.29 die neueste Version. Große Unterschiede zu den vorherigen Versionen seit 2.0 existieren hingegen nicht, es sind vielmehr zahlreiche Kleinigkeiten, die über die Zeit eingeflossen sind. Bei Bedarf werden neue Funktionen aus vergleichsweise neuen Versionen hervorgehoben. Gleiches gilt für möglicherweise ältere Versionen von Git, die sich noch in den Paketverwaltungen älterer Linux-Distributionen finden. Obwohl die Version 2.0 von Git schon über sieben Jahre alt ist, werden an den ein oder anderen Stellen im Buch noch Unterschiede zu den mittlerweile sehr alten Versionen hervorgehoben. Als Neuankömmling sehen Sie so, was sich getan hat, und wenn Sie nach etlichen Jahren Pausen dann doch wieder Git anfassen, dann geht Ihnen auch nichts verloren.
Seit der Version 2.5, die im Mai 2015 erschien, hat Git unter Windows keinen Preview-Status mehr, sondern ist als vollwertige stabile Version verfügbar.
Die Installation unter Windows ist größtenteils selbsterklärend. Ein paar Kleinigkeiten gibt es aber doch zu beachten. Ein Punkt bei der Installation ist die Abfrage des genutzten Editors. In früheren Versionen wurde automatisch der Konsolen-Texteditor »vim« installiert und konfiguriert. Dieser ist vor allem für gängige Windows-Nutzer ohne Erfahrung in der Nutzung von »vim« eine schwierige Wahl. Eine Konfiguration eines anderen Editors war zuvor erst nachträglich möglich.
Abb. 2.1: Die Installation erlaubt die Auswahl verschiedener Editoren.
Mittlerweile können verschiedene Editoren ausgewählt werden. Eine Auswahl davon ist vorgegeben, aber auch andere Editoren lassen sich bereits bei der Installation konfigurieren.
Ein weiterer Punkt sind die Unterschiede bei der Nutzung der Shell. Die Shell ist das Fenster, in dem die Kommandozeilenbefehle eingetippt werden. Git lässt sich sowohl in der Windows-Cmd nutzen als auch in der »Git Bash« verwenden.
Abb. 2.2: Im Standard ist Git sowohl in der Bash als auch in der Windows-Cmd nutzbar.
Wenn Git zusätzlich in der Windows-Cmd genutzt werden soll, muss es in der PATH-Variablen eingetragen werden. Dies ist der Standard, wenn Git installiert wird.
Abb. 2.3: Konfiguration des Verhaltens bezüglich des Zeilenendes
Eine weitere Konfiguration, die während der Installation abgefragt wird, ist die Einstellung bezüglich des Verhaltens des Zeilenendes. Der Standard ist, dass beim Auschecken von Dateien das Zeilenende von LF zu CRLF umgewandelt wird und beim Committen in das Repository wieder in LF. Sofern Sie nicht wissen, was dann genau passiert, sollten Sie die anderen Optionen ausdrücklich nicht auswählen.
Bei der Nutzung von Git präferiere ich die Git-Bash, da sie im Defaultzustand einige zusätzliche Funktionen bietet, wie die Anzeige des Namens des aktuellen Branches. Außerdem können die gängigen Unix-Kommandos verwendet werden. Alle Befehle in diesem Buch lassen sich problemlos in einer Shell unter macOS und Linux bzw. der Git-Bash unter Windows ausführen. Die Windows-Cmd kann zwar auch verwendet werden, allerdings nenne ich Windows-Cmd-Kommandos nicht noch einmal explizit. Dies ist unter anderem dann relevant, wenn etwa Ordner angelegt oder Dateien verschoben werden sollen.
Abb. 2.4: Git-Bash unter Windows
Da Git ein verteiltes Versionsverwaltungsprogramm ist, lassen sich alle Operationen an einem Repository vollständig lokal ausführen. Alle Git-Funktionen, die in diesem Kapitel erläutert werden, sind ohne Ausnahme lokale Befehle auf dem eigenen Rechner. Verbindungen zu externen Git-Servern werden also nicht aufgenommen.
Bevor Sie die ersten Dateien in ein Repository schieben können, müssen sie lokal angelegt werden. Da Git ein Kommandozeilenprogramm ist, müssen Sie jetzt unter Linux oder macOS das Terminal öffnen. Windows-Nutzer rufen an dieser Stelle die Git-Bash auf. Im Defaultzustand landet man dann im Home-Verzeichnis des Nutzerkontos. Dies ist etwa /home/svij unter Linux, C:\Users\svij unter Windows oder /Users/svij unter macOS. In diesem oder in einem anderen beliebigen Verzeichnis legen Sie nun einen Unterordner namens meineWebsite an, in dem das Repository und dessen Daten liegen sollen. Anschließend wechseln Sie mit dem cd-Befehl in das Verzeichnis.
$ mkdir meineWebsite $ cd meineWebsite
In diesem Verzeichnis soll nun das Git-Repository angelegt werden. Dazu reicht ein einfaches Ausführen des folgenden Befehls:
$ git init Hinweis: Als Name für den initialen Branch wurde 'master' benutzt. Hinweis: Dieser Standard-Branchname kann sich ändern. Um den Namen des Hinweis: initialen Branches zu konfigurieren, der in allen neuen Hinweis: Repositories verwendet werden soll und um diese Warnung zu Hinweis: unterdrücken, führen Sie aus: Hinweis: Hinweis: git config --global init.defaultBranch <Name> Hinweis: Hinweis: Häufig gewählte Namen statt 'master' sind 'main', 'trunk' und Hinweis: 'development'. Der gerade erstellte Branch kann mit diesem Hinweis: Befehl umbenannt werden: Hinweis: Hinweis: git branch -m <Name> Leeres Git-Repository in /home/sujee/Repositorys/meineWebsite/.git/ initialisiert
Die Ausgabe des Befehls verrät schon, was passiert ist. Git hat innerhalb des Projekt-Ordners ein .git-Verzeichnis angelegt, in dem das leere Git-Repository liegt. Es liegen zwar Dateien und Verzeichnisse im .git-Verzeichnis, doch ist das Repository prinzipiell leer, da noch keine Daten und keine Revisionen hinterlegt sind. Das Verzeichnis ist auf allen Betriebssystemen versteckt. Das Gedächtnis des Git-Repositorys liegt vollständig im .git-Unterverzeichnis. Falls man das Verzeichnis löscht, sind auch alle gespeicherten Informationen des Repositorys gelöscht. Zum jetzigen Zeitpunkt wäre das natürlich nicht so tragisch, da es noch leer ist.
Hinweis
Kurz vor Drucklegung des Buches erschien Git in Version 2.30. Dort wurden die oben aufgeführten Hinweise ergänzt, damit im Standard Repositorys beim Erstellen nicht mit dem master Branch angelegt werden müssen. Für dieses Buch belasse ich es zunächst bei der Nutzung des master Branches.
Was Branches sind und was die Namen genau zu bedeuten haben, folgt sowieso noch an späterer Stelle.
An dieser Stelle lohnt sich schon ein kleiner Blick in dieses Verzeichnis:
$ ls -l .git insgesamt 12 drwxr-xr-x 1 sujee sujee 0 30. Dez 20:10 branches -rw-r--r-- 1 sujee sujee 92 30. Dez 20:10 config -rw-r--r-- 1 sujee sujee 73 30. Dez 20:10 description -rw-r--r-- 1 sujee sujee 23 30. Dez 20:10 HEAD drwxr-xr-x 1 sujee sujee 414 30. Dez 20:10 hooks drwxr-xr-x 1 sujee sujee 14 30. Dez 20:10 info drwxr-xr-x 1 sujee sujee 16 30. Dez 20:10 objects drwxr-xr-x 1 sujee sujee 18 30. Dez 20:10 refs
Wie Sie sehen, liegen in dem .git-Verzeichnis einige Verzeichnisse und Dateien. Was genau darin passiert, ist an dieser Stelle zunächst irrelevant. Händisch muss in diesem Verzeichnis in der Regel zunächst nichts unternommen werden, außer wenn Sie Hooks – für das Ausführen von Skripten bei diversen Aktionen – oder die Konfiguration anpassen möchten. Allerdings sollten Sie die Dateien nur anfassen, wenn Ihnen bekannt ist, zu welchen Auswirkungen es führt, denn sonst können Sie das Repository kaputtmachen!
Da Sie bereits ein leeres Repository angelegt haben, können Sie nun ein Commit hinzufügen. Was genau ein Commit ist und wie es getätigt werden kann, wird später genau erläutert. Denn zunächst müssen Sie noch die Git-Installation konfigurieren.
Vorerst werden allerdings nur zwei Dinge konfiguriert: der eigene Entwicklername und die dazugehörige E-Mail-Adresse.
Mit den folgenden Befehlen können Sie den eigenen Namen und die eigene E-Mail-Adresse setzen:
$ git config --global user.name "Sujeevan Vijayakumaran" $ git config --global user.email mail@svij.org
An dieser Stelle sollten Sie natürlich dann Ihren Namen und E-Mail-Adresse eintragen und nicht meine Daten.
Mit diesen beiden Befehlen wird die Datei .gitconfig im Home-Verzeichnis angelegt. Der Inhalt der Datei in ~/.gitconfig sieht anschließend so aus:
$ cat ~/.gitconfig
[user]
name = Sujeevan Vijayakumaran
email = mail@svij.org
Mit dem Befehl git config -l lässt sich die Konfiguration ebenfalls über die Kommandozeile ansehen.
Beachten Sie, dass bei den oben genannten Befehlen die Git-Identität global für das Benutzerkonto des Betriebssystems gesetzt wird. Wenn Sie für einzelne Git-Repositorys spezifische Einstellungen setzen möchten, reicht es, den Aufruf-Parameter --global wegzulassen. Die Konfiguration wird dann in die Datei .git/config im Projektordner gespeichert. Dies ist häufig dann sinnvoll, wenn Sie verschiedene E-Mail-Adressen für verschiedene Projekte nutzen. Das trifft beispielsweise dann zu, wenn Sie für die Erwerbsarbeit eine E-Mail-Adresse verwenden und für private Repositorys eine andere. Die angegebenen Informationen zu einem Entwickler sind für alle Personen einsehbar, die mindestens Lese-Rechte im Repository besitzen, sofern der Entwickler mindestens einen Commit getätigt hat.