Versionsverwaltung mit Git

Inhaltsverzeichnis

1 Einführung
1.1 Was ist Git?
1.2 Die Geschichte hinter Git

2 Git-Objekte

3 Arbeiten mit Git
3.1 Installation
3.1.1 Git für Linux
3.1.2 Git für Mac OS
3.1.3 Git für Windows
3.2 Repositories anlegen und verwalten
3.2.1 Lokale Repositories
3.2.2 Remote Repositories
3.3 Branches
3.4 Commit
3.5 Merge, Rebase und Cherry-Picking
3.5.1 Mergen mit Git
3.5.2 Einen Rebase durchführen
3.5.3 Cherry-Picking
3.6 Merge Konflikte lösen
3.7 Die Datei .gitignore
3.8 Konsole vs GUI
3.8.1 Shell
3.8.2 GitHub
3.8.3 TortoiseGit

4 Git Tools
4.1 Stagen
4.2 Stashen
4.3 Debugging mit blame und bisect
4.4 Submodule
4.5 Git Hooks

5 Git und SVN
5.1 Zu Git wechseln
5.2 Bidirektionale Kommunikation

6 Git auf dem Server
6.1 Das Git-Protokoll
6.2 Gitolite
6.3 GitWeb

7 Vor- und Nachteile von Git

1 Einführung

1.1 Was ist Git?

Einfach gesagt ist Git ein Versionskontrollsystem, also ein "Werkzeug, das unterschiedliche Versionen von Software oder anderen Inhalten verwaltet und überwacht".¹ Andere bekannte Systeme sind beispielsweise SVN, CVS oder Bazaar. Man kann diese Systeme in zwei Gruppen unterteilen: Zentrale und dezentrale (verteilte) Systeme. Git gehört in die Gruppe der verteilten Versionskontrollsysteme. In zentralen Systemen gibt es einen Hauptserver, auf dem das Projekt liegt und mit dem sich jeder Entwickler² immer wieder verbindet, um seine Änderungen einzupflegen oder sich die aktuelle Version herunterzuladen. Im Gegensatz hierzu gibt es bei verteilten Versionskontrollsystemen wie Git diverse gleichwertige Instanzen des Repositorys. Jeder Entwickler verfügt über eine vollständige lokale Kopie des Projekts, was zum Einen den Vorteil hat, dass auch ohne permanente Verbindung zum Server gearbeitet werden kann, zum Anderen ist es sicherer. Im Falle, dass der Server zeitweise ausfällt oder sogar ganz und gar beschädigt wird, kann trotzdem weiter an dem Projekt gearbeitet werden und es gäbe weiterhin noch aktuelle Kopien des Projekts.³ In der Praxis existiert wohl in den meisten Fällen aber doch ein zentrales Repository, mit dem die Entwickler ihre lokalen Repositories synchronisieren, da so der Austausch zwischen den Entwicklern erleichtert wird. Wer also eine Änderung vornehmen möchte, lädt sich eine vollständige Kopie der aktuellen Version herunter, bearbeitet diese und schickt sie anschließend wieder an den Server zurück. Durch die lokale Kopie können alle Vorgänge, außer der Synchronisation mit dem entfernten Repository, lokal stattfinden. Sogar Commits und Checkouts finden bei Git zunächst lokal statt (dazu später mehr), genau wie das Einsehen oder Bearbeiten der Versionsgeschichte oder der Wechsel in einen anderen Branch (Entwicklungszweig, s.u.). Eine Internetverbindung ist demzufolge nur selten notwendig.⁴

Eine andere Variante, die ohne zentrales Repository auskommt, ist der "Integration Manager Workflow". Hier gibt es statt des zentralen Repository nur ein quasi-offizielles Repository, das blessed („gesegnet“) genannt wird. Der Zugriff hierauf ist beschränkt und erlaubt nur wenigen, sogenannten "Maintainern", Schreibzugriff. Es darf aber von jedem, der daran arbeiten will, geklont werden. Die Änderungen werden dann nicht direkt zurück übertragen, sondern gehen zunächst in ein öffentliches Developer-Public Repository. Daraufhin sendet der Entwickler an den Maintainer einen sogenannten Pull-Request, also die Aufforderung, die eigenen Änderungen zu übernehmen. Bevor diese Änderungen also ins Haupt-Repository gelangen, können sie vom Maintainer überprüft werden. Der Vorteil dieser Vorgehensweise liegt vor allem darin, dass auch andere interessierte User Zugriff auf die öffentlichen Entwickler-Repositories bekommen können, um zum Beispiel schon kleine Änderungen auszuprobieren, bevor diese in eine offizielle Version eingepflegt werden.⁵

Firmen und Projekte, die aktuell mittels Git entwickeln sind z.B. Google, Microsoft, Twitter, O'Reilly, PostgreSQL, Eclipse, Netflix und natürlich Linux.⁶

1.2 Die Geschichte hinter Git

Da die Arbeit am Linux-Kernel von Entwicklern auf der ganzen Welt betrieben wird, nutzte man dafür ursprünglich das verteile Versionskontrollsystem BitKeeper. Dieses änderte jedoch 2005 seine Lizenz, so dass es nicht mehr kostenlos genutzt werden konnte. Da Linux-Initiator Linus Torvalds mit keiner der zu dieser Zeit verfügbaren Alternativen zufrieden war, beschloss er, sein eigenes Versionskontrollsystem zu entwickeln. Dabei legte er vor allem Wert auf verteilte Entwicklung (durch tausende Entwickler), eine möglichst hohe Effizienz bei der Ausführung, ein Erzwingen von Verantwortlichkeiten (Transparenz darüber, wer welche Änderungen eingefügt hat) und die Unterstützung der verzweigten Entwicklung. Nachdem die Grundlage geschaffen worden war, erblickte Git im April 2005 das Licht der Welt.

Für die Namenswahl von Git gibt es diverse Theorien. Abgesehen davon, dass das Wort im Softwarebereich noch nicht anderweitig belegt war und praktikabel ist, erklärt Linus Torvalds es damit, dass er eben ein egoistischer Kerl sei, und alle seine Projekte nach sich benenne, erst Linux, jetzt Git (was soviel wie "Blödmann" bedeutet). Inzwischen existieren auch vernünftigere Interpretationen wie "Global Information Tracker".⁷

2 Git-Objekte

Alle in einem Repository gespeicherten Daten liegen als Git-Objekte vor. Git unterscheidet dabei lediglich vier Objekttypen: Blobs, Bäume, Commits und Tags.

Blob ist die Kurzform von "Binary Large Object" und enthält den Inhalt einer Datei, aber keine Metadaten, auch nicht den Dateinamen. Ein Blob entspricht immer einer Datei zu einem Zeitpunkt, das heißt bei Änderungen an der Datei wird jede Version als ein Blob dargestellt. Ein Baumobjekt (Tree) repräsentiert eine Ebene von Verzeichnisinformationen, stellt also eine Hierarchie aus Dateien (Blobs) und Unterverzeichnissen (anderen Trees) dar und entspricht demzufolge einem Verzeichnis.

Commit-Objekte enthalten Metadaten für jede Änderung, die im Repository vorgenommen wurde, zum Beispiel den Autor, die Lognachricht, den Zeitpunkt des Commits usw. Sie stellen darüber hinaus aber auch den kompletten Zustand des Projekts zu einem bestimmten Zeitpunkt dar. Das Commit-Objekt enthält also genau eine Referenz auf einen Tree, und zwar auf den Tree des Projekt- Inhalts.

Mit einem Tag kann man einem anderen Objekt, meist einem wichtigen Commit, aber auch einem Blob, einen Namen zuweisen. So lassen sich beispielsweise bestimmte Versionen einer Datei oder Releases eines Projekts leichter wiederfinden.⁸

Die Identifizierung der Git-Objekte in der Objektdatenbank erfolgt über eine eindeutige SHA-1- Summe. Dies ist eine Hexzahl mit 40 Stellen. Theoretisch könnte man also jedes Objekt, egal ob Blob, Commit, Tree oder Tag über dessen SHA-1-Summe wiederfinden, was allerdings wenig praktikabel ist. Die Objektdatenbank ist also im Prinzip eine Hash-Tabelle, in der die SHA-1- Summen als Schlüssel für die gespeicherten Objekte dienen.⁹

Der Git-Objektspeicher ist also ein inhaltsadressierbares Speichersystem. Die Eindeutigkeit ist hier gewährleistet, weil der komplette Inhalt eines Objekts zum Hash-Wert beiträgt. Jede noch so kleine Änderung an einer Datei, selbst der Zeitpunkt der Änderung, verursacht dabei eine Änderung des SHA-1-Hash, wodurch die neue Version der Datei separat indiziert wird.¹⁰

Wie bereits erwähnt, ist es nicht sehr praktisch, wenn man Dateien anhand ihrer SHA-1-Werte referenzieren müsste, und natürlich kann Git Dateien auch mittels ihres Namens finden. Dazu überwacht Git die Pfadnamen und die dazugehörenden Blobs mit dem Index, einem Baumobjekt.¹¹ Der Index ist eine zusätzliche Ebene zwischen dem Arbeitsverzeichnis und dem Repository. Er sammelt die Änderungen, bevor sie durch den eigentlichen Commit in das Repository übertragen werden und beschreibt damit im Prinzip die Verzeichnisstruktur des gesamten Projekts plus eine Menge von geplanten Änderungen.¹² Der Inhalt des Indexes kann vom Benutzer in systematischen, wohldefinierten Schritten geändert werden und erlaubt dadurch eine Trennung zwischen den Entwicklungsschritten selbst und ihrer Bestätigung durch den Commit.¹³ Dabei enthält der Index selbst keinerlei Dateiinhalte, sondern verfolgt lediglich, was der Benutzer mit Commits bestätigen will.¹⁴

Die Unterschiede zwischen dem aktuellen Arbeitsverzeichnis und dem Index kann man sich mit dem Befehl git diff anzeigen lassen. So kann man sehen, was mit dem nächsten Commit in das Repository geschrieben werden würde.¹⁵ Die Unterschiede zwischen dem Index und dem Repository zeigt es jedoch nicht an. Diese kann man mit git status überprüfen. Für den Fall, dass sich Dateien mit dem Status "Untracked" (s.u.) im Arbeitsverzeichnis befinden oder sich verfolgte Dateien geändert haben, listet Git diese hier auf.

Durch den Index und die Tatsache, dass Git den Inhalt der Dateien (über ihre SHA-1-Werte) und nicht die Dateien selbst (über ihre Namen) verfolgt, kann Git interne Datenmanipulationen relativ einfach und effizient durchführen. Außerdem speichert Git, im Unterschied zu den meisten anderen Versionskontrollsystemen, auf effiziente Weise jede Version jeder Datei und nicht die Unterschiede von einer Version zur nächsten.¹⁶

Den Status der Dateien im Arbeitsverzeichnis teilt Git in drei Gruppen ein. Diejenigen, die sich im Repository befinden oder im Index bereitgestellt wurden, haben den Status "Tracked", also verfolgt. Sollen Dateien von Git ignoriert werden, was für Notizen, Compilerausgaben, etc. sehr nützlich ist, können diese in die Datei .gitignore (s.u.) aufgenommen werden und bekommen dadurch den Status "Ignored". Alle übrigen Dateien haben den Status "Untracked". Das sind zum Beispiel alle neu erzeugten Dateien, die noch nicht mittels git add in den Index übertragen wurden.¹⁷

3 Arbeiten mit Git

3.1 Installation

Unabhängig davon, ob man Git ausschließlich über die Konsole benutzen möchte oder über eine GUI (s.u.) muss man es zunächst einmal installieren. Dazu kann man entweder den Quellcode herunterladen und selbst kompilieren oder ein auf das Betriebssystem zugeschnittenes Paket verwenden.

3.1.1 Git für Linux

Die meisten Linux-Distributionen beinhalten bereits eine Git Version, die aber nicht unbedingt die aktuellste sein muss, weswegen es sich empfiehlt, Git aus dem Quellcode zu installieren. So kann man sichergehen, die neueste Version zu haben. Über die Git Homepage http://git- scm.com/download kann man die aktuelle Version herunterladen und mittels

$ tar -zxf git-1.7.2.2.tar.gz

$ cd git-1.7.2.2

$ make prefix=/usr/local all

$ sudo make prefix=/usr/local install

installieren und kompilieren. Alternativ kann man auch ein Installationsprogramm verwenden, wie apt-get auf Debian-basierten Systemen wie z.B. Ubuntu:

$ sudo apt-get install git

3.1.2 Git für Mac OS

Für Mac Benutzer gibt es ein grafisches Git Installationsprogramm, welches über die SourceForge Webseite verfügbar ist: http://sourceforge.net/projects/git-osx-installer/. Alternativ dazu ist auch eine Installation über MacPort möglich. (http://www.macports.org). Mit

$ sudo port install git-core +svn +doc +bash_completion +gitweb

wird Git auf dem System installiert. Zusätzliche Features wie +svn sind optional. Eine weitere Alternative ist die Installation über Homebrew: (http://brew.sh/) mit folgendem Befehl:

$ brew install git

3.1.3 Git für Windows

Für Windows gibt es ein Installationsprogramm unter http://msysgit.github.com/, welches sowohl eine Kommandozeilenversion inklusive SSH Client, als auch die Standard-GUI bereitstellt. Da eigentlich alle Dokumentationen und Quellen zu Git die Unix-Shell verwenden, macht es durchaus Sinn, die mitgelieferte Shell zu verwenden und nicht die native Windows Shell.¹⁸

3.2 Repositories anlegen und verwalten

3.2.1 Lokale Repositories

Der zentrale Bestandteil beim Arbeiten mit Git ist das Repository. Es beinhaltet die Dateien des Projekts sowie alle Informationen, um das Projekt und seine Versionen zu speichern und zu verwalten. Darüber hinaus gibt es bei Git, im Gegensatz zu den meisten anderen Versionskontrollsystemen, auch noch eine Kopie des Repository selbst, und nicht nur der Dateien im Repository. Diese Daten werden alle im Arbeitsverzeichnis in einem versteckten Unterverzeichnis namens .git gespeichert.¹⁹

Dieses Arbeitsverzeichnis ist der sogenannte "Working Tree". Hier werden die Dateien bearbeitet beziehungsweise neue Dateien, die in das Repository übernommen werden sollen, abgelegt. Über einen Commit gelangen diese dann in das Repository. Der Commit enthält neben den Änderungen auch Metadaten, wie den Autor, den Zeitpunkt und eine (möglichst aussagekräftige) Commit Nachricht, die die Änderungen beschreibt. Welche Dateien man genau in seinem aktuellen Arbeitsverzeichnis vorfindet, hängt aber nicht nur vom Repository ab, sondern auch vom aktuellen Branch (Zweig), in dem man sich befindet. Der HEAD bezeichnet dabei eine Referenz auf den neuesten Commit im aktuellen Branch, also die neueste Version.²⁰

Um ein lokales Repository zu erstellen genügt es, in einem Verzeichnis den Befehl git init aufzurufen. Git erstellt dann aus diesem Verzeichnis das Repository. Die dort befindlichen Dateien dem Repository hinzufügen kann man mit git add .. Anschließend kann mit einem Commit der aktuelle Zustand festgehalten werden:

$ cd /path/to/my/project $ git init

$ git add .

$ git commit²¹

Üblicherweise ist der Arbeitsablauf dann so, dass die Änderungen an den Dateien mittels Editor vorgenommen werden, anschließend mit add in den Index geschriebe und am Ende per Commit in das Repository übertragen werden. Natürlich gibt es für jeden der hier gezeigten Git Befehle noch diverse Optionen, auf die hier aber nur bei Bedarf näher eingegangen werden kann. Git add funktioniert wie gezeigt für Dateien, Verzeichnisse und ihre Unterverzeichnisse. Der Status wird dabei von Git von "Untracked" auf "Tracked" geändert.²² Das Gegenstück dazu ist git rm. Damit kann man eine Datei aus dem Index löschen, oder sowohl aus dem Index als auch aus dem Arbeitsverzeichnis, allerdings nicht nur aus dem Arbeitsverzeichnis. Der Verlauf der Datei im Repository wird dabei erhalten, was bedeutet, dass alle Versionen der Datei, die bereits Teil des Verlaufs sind, im Repository erhalten bleiben.²³

Damit man nicht versehentlich mit einer Datei gewollte Änderungen löscht, prüft Git, vor dem Löschen, ob die aktuelle Version dieser Datei mit dem HEAD identisch ist. Falls die Datei dem HEAD oder dem Inhalt des Index entspricht, wird sie gelöscht. Wenn nicht, funktioniert git rm nicht. Es ist allerdings möglich, mit git rm -f ein Löschen trotzdem zu erzwingen. Sollte man aus Versehen etwas gelöscht haben, ist das weniger problematisch, da es in der Natur von Versionskontrollsystemen liegt, frühere Dateien und Versionen wieder herstellen zu können. Mit git checkout HEAD --dateiname stellt Git die letzte Version dieser Datei im Repository wieder her.²⁴

3.2.2 Remote Repositories

In den meisten Fällen wird man mit Git wohl an verteilten Repositories arbeiten. Dazu muss zunächst eine Kopie des gewünschten Repository in einem neuen Ordner im Arbeitsverzeichnis erstellt werden. Mit git clone -b branchname URL verzeichnisname wird ein bestimmter Branch des unter der URL liegenden Repository in den Ordner Verzeichnisname kopiert:

$ git clone -b myBranch git://git.kernel.org/pub/scm/.../linux.git my-linux $ cd my-linux

$ make²⁵

Wenn man keinen Branch spezifiziert, wird der Master Branch genommen, dazu später mehr. Um das lokale Repository mit dem entfernten zu synchronisieren, also dafür zu sorgen, dass beide Commit-Graphen wieder die gleiche Struktur haben, verwendet man die Befehle git fetch beziehungsweise git pull für den Download und git push beziehungsweise git commit für den Upload.²⁶

Der Befehl git fetch holt dabei lediglich die Änderungen aus dem entfernten Repository, fügt sie aber noch nicht in den lokalen Branch ein. Dies geschieht anschließend mittels eines Merge. Da diese Arbeitsschritte relativ häufig gemeinsam vorkommen, bietet git pull eine komfortable Möglichkeit, das Ganze zu beschleunigen, indem es die beiden Schritte vereint. Das Gegenstück zu git pull lautet folglich git push und dient dazu, Änderungen, die vorher mit git commit lokal in das Repository geschrieben wurden, in das entfernte Repository zu übertragen. Ein Commit alleine genügt dabei nicht, was beim Umstieg von anderen Versionskontrollsystemen auf Git für Verwirrung sorgen könnte.²⁷

Git unterstützt verschiedene Transportprotokolle wie ssh, git, http und https. Zum fetchen kann auch ftp beziehungsweise ftps verwendet werden, was allerdings ineffizient und veraltet ist und nicht mehr genutzt werden sollte. Das Git-eigene Protokoll git://URL unterstützt keine Autorisierung und sollte auf ungesichterten Netzwerken nur mit besonderer Vorsicht verwendet werden. Die Syntax für ssh, git und http(s) lautet:

- ssh://[user@]host.xz[:port]/path/to/repo.git/
- git://host.xz[:port]/path/to/repo.git/
- http[s]://host.xz[:port]/path/to/repo.git/²⁸

3.3 Branches

Ein Branch ist im Grunde nichts anderes als eine Abzweigung vom Projekt, auf dem separat entwickelt werden kann. In der Praxis werden Branches häufig verwendet, um zum Beispiel neue Funktionen zu implementieren und zu testen, bevor diese in den Hauptzweig eingepflegt werden. Ebenso gut können Branches für Bugfixes oder zum Vorbereiten von Releases verwendet werden. Außerdem dienen sie zur Erhaltung älterer Softwareversionen oder zur Trennung der Arbeit von mehreren Entwicklern, in dem jeder auf einem eigenen Branch arbeitet. Mit Git ist sowohl die Verwendung von Branches, als auch ihre Zusammenführung (Merge, s.u.) relativ einfach, so dass es durchaus üblich ist, mehrere Branches an einem Tag zu erstellen und nach dem Merge wieder zu löschen.²⁹

Sobald ein neues Repository angelegt wird, erstellt Git einen Branch, den sogenannten Master (analog zum Trunk in anderen Systemen wie SVN). Dieser unterscheidet sich aber nicht von anderen Branches und kann umbenannt oder gelöscht werden, zumindest so lange noch wenigstens ein anderer Branch zur Verfügung steht.³⁰

Git lässt dabei beliebig viele Zweige zu und eine beliebig komplexe Verzweigungsstruktur. Wichtig ist, dass ein Zweig immer auf einem vorhandenen Commit innerhalb des Repository beruhen muss.

Von diesem Commit können durchaus mehrere Zweige abgespalten werden, ebenso sind sich verzweigende Zweige gestattet.³¹ Um dabei die Übersicht zu behalten, gibt es diverse Tools zur Visualisierung. Unter GitHub kann man sich im Bereich Branches einen Graphen anzeigen lassen, wer auf der Konsole arbeitet, kann dies mit gitk --all tun:³²

Abbildung 1: Darstellung der Branches mit gitk

Im aktuellen Arbeitsverzeichnis arbeitet man jedoch immer nur auf einem Branch. Um diesen zu wechseln, muss man mit git checkout -b branchname in den gewünschten Branch wechseln.³³ Einen neuen Branch kann man mit git branch neuerBranch erstellen. Git nimmt dann den aktuell ausgecheckten Commit als Grundlage und legt dessen SHA-1-Wert in der Datei .git/refs/head ab. Dieses Kommando ist extrem schnell, da Git keine Dateien kopieren oder neue Metadaten erstellen muss. Alle Informationen über die Vorgeschichte sind durch die Referenz auf den Ausgangscommit ableitbar.³⁴

Da die SHA-1-Summe, wie bereits erwähnt, zum Wiederfinden von Dateien oder bestimmten Commits wenig praktisch ist, kann zu jedem Commit ein Tag hinzugefügt werden. Diese referenzieren, wie Branches auch, ein Objekt. Im Gegensatz zu Branches sind sie jedoch statisch und werden mit neuen Commits nicht verschoben, sondern zeigen immer auf dasselbe Objekt. Sie dienen vor allem dazu, die Entwicklungsgeschichte zu dokumentieren und bestimmte Versionen hervorzuheben und wiederfindbar zu machen. Man kann zwei Arten von Tags unterscheiden: Annotated Tags sind mit Anmerkungen versehen, also mit Metadaten wie dem Autor, einer Beschreibung usw., lightweight Tags hingegen haben keine Metadaten und dienen als reine Zeiger auf ein Objekt.³⁵

3.4 Commit

Ein Commit ist im Grunde immer eine Momentaufnahme des Index, der im Objektspeicher abgelegt wird. Dabei werden wie gesagt keine Kopien der Dateien und Objekte erzeugt, (was Unmengen von Speicherplatz kosten würde), sondern der Index wird mit seiner vorherigen Version abgeglichen und Git erstellt eine Liste der von Änderungen betroffenen Dateien und Verzeichnisse. Für alle diese Dateien und Verzeichnisse werden dann neue Blobs erzeugt, während alle ohne Änderungen wiederverwendet werden. Obwohl dieser Prozess sehr aufwendig wirkt, verläuft er sehr schnell und effizient, weil nicht die Inhalte von Dateien, sondern ihre SHA-1-Summen verglichen werden. Wenn zwei Objekte, wie zum Beispiel zwei Bäume, die gleiche SHA-1-Summe haben, sind sie identisch. In dem Git so Teilbäume aussortieren kann, vermeidet es unnötige rekursive Vergleiche.³⁶

Den Commit Verlauf implementiert Git als gerichteten azyklischen Graphen, in dem jeder Knoten einen Commit darstellt. Die Kanten verlaufen von den Nachfahrenknoten zu den Elternknoten:³⁷

Abbildung 2: Vereinfachter Commit-Graph

Neben dem Verfolgen von Änderungen dient ein Versionskontrollsystem wie Git aber natürlich auch dem Wiederherstellen älterer Versionen von Dateien oder ganzen Repository-Zuständen. Außerdem müssen gelegentlich bestimmte Änderungen rückgängig gemacht werden. Für diese Schritte gibt es die Kommandos checkout, reset und revert.³⁸

Das Kommando git checkout kann, wie oben beschrieben, sowohl zum Wechseln in einen anderen Branch verwendet werden, als auch um eine frühere Version des aktuellen Branches wiederherzustellen. Mit git checkout revision . (im Hauptverzeichnis des Projekts ausgeführt) wird der entsprechende Commit wiederhergestellt. Für revision wird entweder die SHA-1-Summe eingesetzt, oder, wenn vorhanden, der Tag. Mit dem Kommando git revert kann man die Änderungen, die durch einen Commit entstanden sind, rückgängig machen. Dabei wird der Commit nicht gelöscht, sondern es wird lediglich ein neuer erstellt, dessen Änderungen genau dem Gegenteil des vorhergehenden Commits entsprechen: Gelöschtes wird hinzugefügt und umgekehrt. Natürlich kann man das auch für einzelne Dateien machen. Will man tatsächlich einen Commit gänzlich löschen, kann man dies mit git reset. Danach zeigt der HEAD und wahlweise auch der Index auf einen bestimmten Commit. Der andere Commit ist zwar zunächst noch da, aber so lange kein Branch mehr auf ihn zeigt, nicht erreichbar. Git löscht solche Commits nach 30 Tagen automatisch, bis dahin könnte man wieder einen Branch erzeugen, der auf diesen Commit zeigt.³⁹

[...]

---

¹ [LOE] - S. 24

² Aus Gründen der Leserlichkeit beschränke ich mich auf die männliche Variante.

³ [GITBU.CH] - S. 1

⁴ [GITBU.CH] - S. 131

⁵ [GITBU.CH] - S. 155ff

⁶ [LAS] - S. 5

⁷ [LOE] - S. 1ff

⁸ [GITBU.CH] - S. 34

⁹ [GITBU.CH] - S. 36

¹⁰ [LOE] - S. 36

¹¹ [LOE] - S. 43

¹² [LOE] - S. 51

¹³ [LOE] - S. 35

¹⁴ [LOE] - S. 52

¹⁵ [LOE] - S. 117

¹⁶ [LOE] - S. 36f

¹⁷ [LOE] - S. 52f

¹⁸ [CHA] - Kapitel 1.4, 21.12.2017

¹⁹ [LOE] - S. 33f

²⁰ [GITBU.CH] - S. 2

²¹ [MAN], 21.12.2017

²² [LOE] - S. 54

²³ [LOE] - S. 58

²⁴ [LOE] - S. 60

²⁵ [MAN], 21.12.2017

²⁶ [GITBU.CH] - S. 139

²⁷ [GITBU.CH] - S. 143

²⁸ [MAN], 21.12.2017

²⁹ [GITBU.CH]- S. 45

³⁰ [GITBU.CH] - S. 3

³¹ [LOE] - S. 101

³² https://stackoverflow.com/questions/5361019/viewing-full-version-tree-in-git, 21.12.2017

³³ [LOE] - S. 105

³⁴ [GITBU.CH] - S. 51

³⁵ [GITBU.CH] - S. 55

³⁶ [LOE] - S. 71

³⁷ [LOE] - S. 83

³⁸ [GITBU.CH] - S. 62

³⁹ [GITBU.CH] - S. 65