Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: MITP
- Kategorie: Wissenschaft und neue Technologien
- Serie: mitp Professional
- Sprache: Deutsch
- Von grundlegenden Funktionen über die Handhabung von Branches und Remote-Repositorys bis zu Tipps und Tricks für (nicht nur) alltägliche Funktionen
- Auswahl sinnvoller Workflows und Einsatz in Teams
- Git-Repositorys hosten mit GitHub und GitLab
Git ist in der Softwareentwicklung bereits weit verbreitet – sowohl in Firmen als auch in Open-Source-Projekten. Zum Einstieg lernen Anfänger häufig nur die wichtigsten Befehle, die schnell nicht mehr ausreichen, vor allem wenn die ersten Fehler auftreten.
Dieses Buch behandelt einerseits die gängigen Befehle, die Sie beim täglichen Arbeiten mit Git brauchen. Andererseits geht es dem Autor auch darum, dass Sie Git als Ganzes verstehen, um es effektiv im Entwicklungsprozess einsetzen zu können.
Der Fokus des Buchs liegt auf dem praktischen Arbeiten mit Git. Sie lernen anhand eines Projekts, welche Befehle es gibt, wie diese arbeiten und wie Sie auftretende Probleme lösen können. Neben alltäglichen Funktionen finden Sie auch seltener gebrauchte Kommandos, die aber ebenfalls wichtig sind. Dabei legt der Autor großen Wert auf die Einbindung und Anpassung des Entwicklungsprozesses.
Im zweiten Teil des Buchs werden fortgeschrittene Themen behandelt. Der Schwerpunkt liegt auf dem Einsatz von Git in Teams. Darunter etwa das Hosten verteilter Repositorys mit GitHub und GitLab. Ein weiteres Kapitel behandelt die Workflows, die je nach Anzahl der beteiligten Personen, Branches und Repositorys eines Projekts variieren.
Darüber hinaus gibt Ihnen der Autor hilfreiche Informationen für den Umstieg von Subversion, einen Überblick über grafische Git-Programme, Hinweise für eine langfristig nachvollziehbare Git-Historie sowie eine Einführung in DevOps, wofür Git die technische Grundlage bildet. Ein Kapitel zu häufig gestellten Fragen rundet diesen Praxiseinstieg ab.
Das Buch richtet sich sowohl an blutige Einsteiger als auch an erfahrene Leser.
Aus dem Inhalt:
- Konfiguration
- Arbeiten mit Branches
- Verteilte Repositorys
- Hosting mit GitHub und GitLab
- Workflows
- Hooks
- Umstieg von Subversion
- Zahlreiche Tipps für die tägliche Arbeit
- Grafische Clients
- Tipps für nachvollziehbare Git-Historien
- Frequently Asked Questions
- Einstieg in DevOps
- Befehlsreferenz
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 391
Veröffentlichungsjahr: 2021
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Sujeevan Vijayakumaran
Versionsverwaltung mit Git
Praxiseinstieg
Impressum
Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.d-nb.de> abrufbar.
ISBN 978-3-7475-0306-5 3. Auflage 2021
www.mitp.de E-Mail: [email protected] Telefon: +49 7953 / 7189 - 079 Telefax: +49 7953 / 7189 - 082
© 2021 mitp Verlags GmbH & Co. KG
Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Lektorat: Sabine Schulz Sprachkorrektorat: Petra Heubach-Erdmann Coverbild: Verne Ho @verneho / unsplash.com, Coverbild gestaltet von Bernhard Hanakamelectronic publication: III-satz, Husby, www.drei-satz.de
Dieses Ebook verwendet das ePub-Format und ist optimiert für die Nutzung mit dem iBooks-reader auf dem iPad von Apple. Bei der Verwendung anderer Reader kann es zu Darstellungsproblemen kommen.
Der Verlag räumt Ihnen mit dem Kauf des ebooks das Recht ein, die Inhalte im Rahmen des geltenden Urheberrechts zu nutzen. Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheherrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und Einspeicherung und Verarbeitung in elektronischen Systemen.
Der Verlag schützt seine ebooks vor Missbrauch des Urheberrechts durch ein digitales Rechtemanagement. Bei Kauf im Webshop des Verlages werden die ebooks mit einem nicht sichtbaren digitalen Wasserzeichen individuell pro Nutzer signiert.
Bei Kauf in anderen ebook-Webshops erfolgt die Signatur durch die Shopbetreiber. Angaben zu diesem DRM finden Sie auf den Seiten der jeweiligen Anbieter.
Cheat Sheet
Repositorys anlegen
git init [<pfad>]
Erzeugt ein neues leeres Repository im aktuellen Arbeitsverzeichnis. Bei optionaler Angabe des Zielpfades wird ein neues Verzeichnis mit dem Repository darin angelegt.
git clone <repository> [<pfad>]
Klont das als weiteren Parameter angegebene Repository in ein neues Verzeichnis im aktuellen Verzeichnis. Zusätzlich wird es als Remote-Repository origin konfiguriert. Bei der Angabe eines weiteren Verzeichnisses wird das Repository unter einem anderen Verzeichnisnamen geklont.
Erweiterung und Bearbeitung der Historie
Arbeiten im Staging-Bereich
git add <pfad>
Mit diesem Befehl können Änderungen von Dateien zum Staging-Bereich hinzugefügt werden, die anschließend in einem Commit gespeichert werden können.
git reset
Setzt den aktuellen HEAD auf einen bestimmten Stand zurück. Anwendbar sowohl bei Änderungen, die noch nicht in einem Commit sind, als auch bei Änderungen in diversen Commits.
git restore
Setzt Dateien im Arbeitsverzeichnis des Repositorys zurück. Mit --source kann optional die Quelle angegeben werden. Mit --staged kann eine Änderung aus dem Staging-Bereich wieder herausgenommen werden.
Arbeiten mit Commits und Branches
git commit
Erzeugt einen Commit aus den Änderungen aus dem Staging-Bereich. Ohne zusätzlichen Parameter öffnet sich der konfigurierte Editor. Alternativ kann die Commit-Message mit -m direkt beim Aufruf gesetzt werden.
git branch [<name>]
Listet alle lokalen Branches auf und erzeugt einen neuen Branch mit dem angegebenen Namen. Dabei wird nicht auf den neuen Branch gewechselt.
git checkout [<branch>]
Wechselt auf den angegebenen Branch. Mit -b kann optional ein neuer Branch erstellt werden, auf den direkt gewechselt wird.
git switch [<branch>]
Wechselt ebenfalls auf den angegebenen Branch und ist ab Git Version 2.23 verfügbar. Mit -c kann optional ein neuer Branch erstellt werden, auf den direkt gewechselt wird.
git diff
Zeigt die Unterschiede zwischen Commits, Commits und Arbeitsverzeichnisse, oder Commits und Staging-Bereich an.
git merge <branch>
Führt mindestens zwei Branches zusammen.
git rebase
Übernimmt Commits von anderen Branches und fügt diese auf dem aktuellen Branch an.
Verteilte Repositorys
git fetch
Lädt alle Objekte des konfigurierten Remote-Repositorys herunter und macht sie lokal zugänglich. Häufig werden mit dem Parameter alle Daten von allen konfigurierten Remote-Repositorys heruntergeladen.
git pull
Lädt die Änderungen vom konfigurierten Branch vom Remote-Repository und führt ein Merge oder Rebase durch.
git push
Schiebt die lokalen Commits des Branches auf den Server.
git remote
Ermöglicht die Konfiguration von Remote-Repositorys.
Status im Repository
git status
Zeigt den Status im Repository an und gibt sehr hilfreiche Informationen aus, welche folgenden Befehle nun ausgeführt werden können.
git log
Zeigt die Historie des Repositorys an.
Multi-Repositorys verwalten
git subtree
Ermöglicht die Einbindung von anderen Git-Repositorys in das aktuelle Repository, in dem das Subtree in das Repository gemerget wird.
git submodule
Ermöglicht ebenfalls die Einbindung von anderen Git-Repositorys in das aktuelle Repository. Die Submodule-Repositorys werden über ein Commit referenziert und eingebunden.
Sonstiges
git blame <pfad>
Zeigt für die angegebene Datei Zeile für Zeile an, wer die Zeile zuletzt modifiziert hat, inklusive Commit-ID und Zeitpunkt.
git stash
Schiebt Änderungen aus dem aktuellen Arbeitsverzeichnis in einen Zwischenspeicher und kann diese Änderungen auch erneut wieder herausholen.
git config
Ermöglicht es, die Konfiguration anzupassen.
git reflog
Zeigt an, welche Tätigkeiten lokal im Repository ausgeführt wurden. Ist sehr nützlich, wenn Commits aus Versehen gelöscht wurden.
git clean
Räumt das lokale Repository auf, etwa um ignorierte oder nicht versionierte temporäre Dateien gesammelt zu entfernen.
Einleitung
»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.
Aufbau des Buches
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.
Konvention
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:
Zeilen, die nicht relevant sind oder verkürzt wurden, sind als »[...]« dargestellt.
Hinweise und Tipps
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.
Feedback
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 [email protected] oder Kurzes gerne auch via Twitter an @svijee (https://twitter.com/svijee). Ich bin sehr an Ihrem Feedback interessiert!
Danksagung
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/)
Kapitel 1: Einführung
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.
1.1 Lokale 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.
1.2 Zentrale Versionsverwaltung
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.
1.3 Verteilte Versionsverwaltung
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.
1.4 Geschichtliches
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.
Kapitel 2: Die Grundlagen
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.
2.1 Installation
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
2.2 Das erste Repository
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.
In diesem Verzeichnis soll nun das Git-Repository angelegt werden. Dazu reicht ein einfaches Ausführen des folgenden Befehls:
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:
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!
2.4 Der erste Commit
An dieser Stelle startet das »echte« Arbeiten mit dem Git-Repository. Wie bereits vorher erwähnt, sind sowohl das Arbeitsverzeichnis als auch das Repository leer. Sie müssen daher einige Dateien in das Arbeitsverzeichnis schieben.
Zuvor lohnt sich noch ein Ausführen des Git-Kommandos gitstatus:
Dieser Befehl gibt immer sinnvolle und praktische Informationen aus, die für das Arbeitsverzeichnis und für das Repository zu der entsprechenden Zeit hilfreich sind. Zum jetzigen Zeitpunkt teilt es mit, dass man sich auf dem Branch master befindet, noch keine Commits vorhanden sind und es noch nichts zu committen gibt. Es handelt sich demnach um ein noch leeres Repository.
Jetzt ist es an der Zeit, die ersten Dateien hinzuzufügen und den ersten Commit zu tätigen. Da in diesem Beispielprojekt das HTML5-Framework Bootstrap verwendet wird, müssen Sie dieses zunächst herunterladen und entpacken. Dies kann entweder händisch geschehen oder Sie führen folgende Befehle aus. Falls curl nicht installiert ist, was bei einigen Linux-Distributionen der Fall sein kann, können Sie es nachinstallieren, das Programm wget nutzen oder die Datei über den angegebenen Link händisch über den Browser herunterladen und entpacken.
Einige der aufgeführten Befehle geben Text auf der Standard-Ausgabe aus, die ich hier aus Gründen der Übersichtlichkeit weggelassen habe. Über die Befehle wurde der Download getätigt, die Zip-Datei entpackt und somit ihr Inhalt in das Projektverzeichnis geschoben. Anschließend liegen im Projektverzeichnis dann zwei Unterverzeichnisse: css und js.
Abb. 2.5: Das Arbeitsverzeichnis ist gefüllt, Repository und Staging sind leer.
Obwohl die Dateien und Ordner im Projektordner liegen, sind die Dateien noch nicht im Repository. Sie müssen Git immer explizit mitteilen, dass Dateien in das Repository geschoben werden sollen.
Generell ist es durchaus häufig sinnvoll, den aktuellen Status im Arbeitsverzeichnis zu prüfen, deshalb lohnt sich jetzt ein Blick auf die Ausgabe von gitstatus:
Wie zu lesen ist, zeigt Git an, dass unbeobachtete Dateien vorhanden sind. Bei unbeobachteten Dateien handelt es sich um Dateien, die bisher nicht von Git verwaltet werden und somit noch unbekannt sind. Eine Versionierung der Dateien findet noch nicht statt. Mit dem Befehl gitadd können Sie nun Dateien zu dem sogenannten Staging-Bereich hinzufügen. Das ist der Bereich, in dem die Dateien hinzugefügt werden, um sie für einen Commit vorzumerken. Es ist dadurch eine Zwischenstufe zu einem Commit und wird häufig auch einfach kurz »Staging« oder »Index« genannt. Wenn im Git-Kontext von »Index« oder »Staging« die Rede ist, dann ist es genau dasselbe. Um die Dateien für einen Commit vorzumerken, müssen Sie den Ordner css zum Staging-Bereich hinzufügen:
Eine Ausgabe erfolgt an dieser Stelle nicht. Mit gitstatus lässt sich erneut nachvollziehen, was geschehen ist, dies sieht dann wie folgt aus:
Die Status-Ausgabe stellt Verzeichnisse und Dateien unterschiedlich dar. Das Verzeichnis js wird mit abschließendem Schrägstrich / dargestellt. Dadurch ist auf den ersten Blick zu erkennen, dass es sich um ein Verzeichnis und nicht um eine normale Datei handelt. Beim Hinzufügen zum Staging-Bereich müssen diese Schrägstriche nicht mit angegeben werden. Durch das Hinzufügen des Ordners css werden die einzelnen Dateien für den nächsten Commit vorgemerkt, da sie sich nun im Staging-Bereich befinden. Der Befehl gitadd hat also nicht viel mehr gemacht, als den Staging-Bereich zu füllen, indem es die zuvor noch nicht bekannten Daten dem Repository erstmals bekannt gemacht hat. An dieser Stelle ist allerdings immer noch kein Commit erstellt worden. Wenn Sie statt eines ganzen Verzeichnisses mit allen Dateien lieber nur einzelne Dateien hinzufügen möchten, geht das natürlich auch:
Auch hier erfolgt erneut keine Ausgabe, wenn die Ausführung erfolgreich war. An dieser Stelle bietet sich ein erneuter Blick auf den Status an:
Der vorherige Befehl hat das komplette css-Verzeichnis zum Staging-Bereich hinzugefügt. Mit dem Hinzufügen einer einzelnen Datei wird von gitstatus nicht mehr der Ordner allgemein, sondern explizit alle Dateien aufgelistet.
Tipp
Wer eine kleinere und kürzere Status-Ausgabe haben möchte, kann den Parameter -s anhängen.
Der Befehl mit diesem Parameter gibt eine kürzere Ausgabe aus und beschränkt sich auf die nötigsten Ausgaben. Vor den Dateien stehen Buchstaben, die den Status angeben. »A« steht für »Added«, also wenn sich die Dateien im Staging-Bereich befinden. »??« ist für Dateien, die bisher noch nicht beobachtet werden. Weiterhin existiert noch ein » M« und ein »M «, zu beachten ist das Leerzeichen jeweils vor bzw. hinter dem »M«. Bei Ersterem handelt es sich um eine veränderte Datei, die sich im Staging-Bereich befindet, bei Letzterem wiederum handelt es sich um eine Datei, die sich nicht im Staging-Bereich befindet.
Der nächste Befehl fügt alle restlichen Dateien, die noch nicht beobachtet werden, hinzu:
Abb. 2.6: Staging ist gefüllt, das Repository ist noch immer leer.
Wie an der Abbildung zu sehen ist, hat dieser Schritt den Staging-Bereich vollständig gefüllt. Es befinden sich alle Verzeichnisse des Arbeitsverzeichnisses im Staging-Bereich und sind bereit, in den ersten Commit und somit in das Repository geschoben zu werden.
Statt die Verzeichnisse einzeln hinzuzufügen, können Sie auch gitadd-A ausführen, um generell alle unbeobachteten und gegebenenfalls veränderten Dateien dem Staging-Bereich hinzuzufügen. Allerdings sollten Sie dabei stets aufpassen. Wenn Sie sichergestellt haben, dass keine anderen temporären Dateien vorhanden sind, können Sie den Befehl problemlos ausführen. Das ist in diesem Beispiel der Fall. Im Laufe von Entwicklungsarbeiten liegen aber häufig temporäre Dateien im Projektverzeichnis, die nicht in das Repository sollen. Falls doch die ein oder andere Datei unbeabsichtigt hinzugefügt wurde und diese gar nicht mit in den nächsten Commit soll, dann kann man sie mit gitrm--cached$DATEINAME einfach wieder herausnehmen. Der Parameter --cached ist hierbei wichtig, denn sonst wird die Datei gelöscht!
Nach einem erneuten Ausführen von gitstatus werden alle dem Staging-Bereich hinzugefügten Dateien aus den zwei Unterordnern aufgelistet. Es bietet sich nicht nur für Anfänger an, jedes Mal zu überprüfen, ob die richtigen Dateien hinzugefügt wurden, bevor der Commit getätigt wird.
Hiermit können Sie verifizieren, dass wirklich alle neuen Dateien hinzugefügt und keine vergessen wurden. Nach der Überprüfung können Sie den ersten Commit erzeugen. Er enthält dann genau die Dateien, die Sie zuvor mit gitadd zum Staging-Bereich hinzugefügt haben. Dateien, die gegebenenfalls ausgelassen wurden, bleiben unangetastet.
Aber was ist nun ein Commit? Ein Commit ist ein »Snapshot« aller im Dateien. Es ist quasi eine vollständige Version die abgespeichert wird, damit Sie später zwischen den Versionen hin- und herspringen können und sich die Unterschiede anzeigen lassen können. Referenziert werden die Commits über eine 40-stellige ID, wobei da in der Regel die kurze Variante mit nur 7 Stellen genutzt werden kann.
Mit dem folgenden Befehl wird der erste Commit erzeugt:
Abb. 2.7: Der erste Commit ist getätigt, Staging ist anschließend leer.
Der Befehl gitcommit speichert die Dateien aus dem aktuellen Staging-Bereich in einen Commit. Mit dem Parameter -m können Sie eine Commit-Nachricht direkt übergeben. Diese fasst in der Regel die aktuellen Änderungen zusammen, sodass sowohl Sie als auch andere Mitarbeiter mit Zugang zu dem Repository die Änderungen in dem Commit möglichst schnell und einfach nachvollziehen können. Wichtig ist vor allem, dass beschrieben wird, warum etwas getätigt wurde und nicht was. Was geändert wurde, ist im Commit selbst ersichtlich. In diesem Beispielprojekt ist das hingegen noch nicht sehr relevant. Wie in der Abbildung verdeutlicht wird, ist der Staging-Bereich nach dem Commit leer. Der Prozess beim Committen sieht also prinzipiell so aus, dass die Änderungen – dazu zählen auch neue Dateien – zwischen die »Schichten« geschoben werden. Wenn Sie Dateien mit gitadd hinzufügen und mit gitcommit den Commit erzeugen, gehen die Dateien jeweils eine Schicht nach oben. Mit gitreset können Sie die Änderungen auf verschiedene Arten wieder auf die unteren Schichten holen. Dazu folgen allerdings an späterer Stelle mehr Informationen. Zum Schluss sind vier statt drei Schichten dargestellt. Neben »Untracked« gibt es noch »Unmodified«. In »Untracked« liegen die unbeobachteten Dateien und in »Unmodified« nach dem ersten Commit die Dateien, die verändert werden könnten.
Hinweis
Wenn allerdings der Commit-Befehl ohne den Parameter -m ausführt wird, öffnet sich stattdessen der Standard-Editor, in dem dann die Commit-Nachricht eingetippt werden kann. Dies ist häufig der Konsoleneditor »vim«. Mit dem folgenden Befehl kann man den Editor auf den simplen Konsoleneditor »nano« ändern:
Bei Windows-Nutzern wird bei der Installation von Git die Konfiguration des Standard-Editors abgefragt. Wer dies verpasst hat, kann auch unter Windows »nano« nutzen. Alternativ lässt sich auch der persönlich präferierte Editor nutzen, wozu man statt nano den Namen oder direkten Pfad zum Editor im obigen Befehl angeben muss. Für Notepad++ sähe das dann so aus:
Nach dem ersten Commit können Sie noch einmal den gitstatus-Befehl ausführen:
