Git. Versionskontrolle. O Reilly. Deutsche Ausgabe. Projekte effizient und flexibel verwalten. Jon Loeliger

Transkript

1 Projekte effizient und flexibel verwalten Versionskontrolle Git mit Deutsche Ausgabe O Reilly Jon Loeliger Deutsche Übersetzung von Kathrin Lichtenberg

2 Inhalt Vorwort VII 1 Einführung Hintergrund Die Geburt von Git Die Vorgeschichte Der weitere Verlauf Namen sind Schall und Rauch? Git installieren Die Linux-Binärdistributionen benutzen Eine Quellversion beschaffen Kompilieren und Installieren Git unter Windows installieren Erste Schritte Die Git-Kommandozeile Kurze Einführung in die Benutzung von Git Konfigurationsdateien Ausblick Grundlegende Git-Konzepte Grundlegende Konzepte Darstellungen des Objektspeichers Git-Konzepte am Werk III

3 5 Dateiverwaltung und der Index Es geht um den Index Dateiklassifikationen in Git git add benutzen Einige Hinweise zur Benutzung von git commit git rm benutzen git mv benutzen Ein Hinweis zum Überwachen des Umbenennens Die Datei.gitignore Eine ausführliche Darstellung des Objektmodells und der Dateien von Git Commits Atomare Änderungsmengen (Changesets) Commits festlegen Der Commit-Verlauf Commits suchen (und finden) Zweige Gründe für den Einsatz von Zweigen Zweignamen Zweige benutzen Zweige erzeugen Zweignamen auflisten Zweige anschauen Zweige auschecken Zweige löschen Diffs Formen des git diff-befehls Ein einfaches git diff-beispiel git diff und Commit-Bereiche git diff mit Pfadbegrenzung Wie Subversion und Git Diffs ableiten ein Vergleich Merges Merge-Beispiele Mit Merge-Konflikten arbeiten Merge-Strategien Wie Git über Merges denkt IV Inhalt

4 10 Commits verändern Vorsicht beim Verändern des Verlaufs git reset benutzen git cherry-pick benutzen git revert benutzen reset, revert und checkout Das oberste Commit ändern Rebasing von Commits Entfernte Repositories Repository-Konzepte Auf andere Repositories verweisen Ein Beispiel mit entfernten Repositories Entfernte Repository-Operationen in Bildern Entfernte Zweige hinzufügen und löschen Remote-Konfiguration Bare-Repositories und git push Repositories veröffentlichen Repository-Verwaltung Die Repository-Struktur In einer verteilten Entwicklung leben Wissen, wo Sie stehen Mit mehreren Repositories arbeiten Patches Wozu Patches benutzen? Patches generieren Patches per verschicken Patches anwenden Schlechte Patches Patching und Merging im Vergleich Hooks Einstiegspunkte für die Automatisierung Hooks installieren Verfügbare Hooks Projekte kombinieren Die alte Lösung: partielle Checkouts Die offensichtliche Lösung: den Code in Ihr Projekt importieren Inhalt V

5 Die automatisierte Lösung: Teilprojekte mit eigenen Skripten auschecken Die native Lösung: Gitlinks und git submodule Git mit Subversion-Repositories benutzen Beispiel: ein einfacher Klon eines einzigen Zweigs Verschieben, Ziehen, Verzweigen und Zusammenführen mit git svn Verschiedene Hinweise zum Arbeiten mit Subversion Index VI Inhalt

6 Kapitel 1 KAPITEL 1 Einführung Hintergrund Niemand, der bei einigermaßen klarem Verstand ist, startet ein Projekt heutzutage ohne Backup-Strategie. Da die Daten vergänglich sind und leicht verloren gehen können sei es durch eine irrtümliche Codeänderung oder einen katastrophalen Festplatten-Crash, tut man gut daran, ein lebendiges Archiv seiner gesamten Arbeit vorzuhalten. Bei Text- und Codeprojekten umfasst diese Backup-Strategie üblicherweise eine Versionskontrolle oder die Verfolgung und Verwaltung von Änderungen. Jeder Entwickler darf mehrere Änderungen pro Tag vornehmen. Die stetig anwachsende Sammlung dient gleichzeitig als Repository (Lager), Projektgeschichte, Kommunikationsmedium und Werkzeug zur Team- und Produktverwaltung. Angesichts ihrer zentralen Rolle funktioniert die Versionskontrolle am effektivsten, wenn sie auf die Arbeitsgewohnheiten und -ziele des Projektteams zugeschnitten ist. Ein Werkzeug, das unterschiedliche Versionen von Software oder anderen Inhalten verwaltet und überwacht, wird im Allgemeinen als Versionskontrollsystem (Version Control System; VCS), Source Code Manager (SCM), Revision Control System (RCS) oder mit anderen Kombinationen der Wörter»Revision«,»Version«,»Code«,»Content«,»Control«,»Management«und»System«bezeichnet. Auch wenn sich die Autoren und Benutzer der einzelnen Programme möglicherweise über esoterische Dinge streiten, dienen alle Systeme den gleichen Problemstellungen: der Entwicklung und Pflege eines Repository mit Inhalten, der Ermöglichung des Zugriffs auf historische Ausgaben der einzelnen Daten und der Aufzeichnung aller Änderungen in einem Log. In diesem Buch bezieht sich der Begriff Versionskontrollsystem ganz allgemein auf jede Form solcher Systeme. Dieses Buch behandelt Git, eine besonders leistungsstarke und flexible Versionskontrolle mit geringem Overhead, die gemeinschaftliche Entwicklung begünstigt. Git wurde von Linus Torvalds erfunden, um die Entwicklung des Linux-Kernels zu unterstützen. Mittlerweile hat es sich bei einer Vielzahl unterschiedlicher Projekte bewährt. 1

7 Die Geburt von Git Existiert ein Missverhältnis zwischen einem Werkzeug und einem Projekt, stellen die Entwickler oft einfach ein neues Werkzeug her. Um genau zu sein, ist die Verlockung, sich neue Werkzeuge zu schaffen, in der Welt der Software meist unglaublich groß. Angesichts der vielen vorhandenen Versionskontrollsysteme sollte man allerdings nicht leichtfertig beschließen, ein weiteres herzustellen. Bei entsprechendem Bedarf, einer gewissen Einsicht und einer gehörigen Portion Motivation kann es sich jedoch als völlig richtig erweisen, ein neues Werkzeug aus dem Boden zu stampfen. Git, das von seinem Schöpfer auch liebevoll als»information Manager from Hell«bezeichnet wird, ist ein solches Werkzeug. Die genauen Umstände und der exakte Zeitpunkt seiner Entstehung sind zwar im Zuge des politischen Gezänks innerhalb der Linux-Kernel-Community untergegangen, aber es besteht kein Zweifel daran, dass mit Git ein wohldurchdachtes Versionskontrollsystem geschaffen wurde, das in der Lage ist, die weltweit verteilte Entwicklung von Software in großem Maßstab zu unterstützen. Vor Git wurde bei der Entwicklung des Linux-Kernels das kommerzielle System BitKeeper benutzt, das komplizierte Operationen ermöglichte, die von den damaligen freien Versionskontrollsystemen wie RCS und CVS nicht geboten wurden. Als jedoch das Unternehmen, dem BitKeeper gehörte, im Frühjahr 2005 seine freie, d. h. kostenlose Version weiter einschränkte, fand die Linux-Gemeinschaft, dass BitKeeper keine praktikable Lösung mehr darstellte. Linus suchte nach Alternativen. Kommerzielle Lösungen meidend, untersuchte er die freien Softwarepakete, fand bei ihnen jedoch die gleichen Einschränkungen und Mängel, die bereits früher zu ihrer Ablehnung geführt hatten. Was stimmte nur nicht mit den vorhandenen Versionskontrollsystemen? Welche exotischen Funktionen oder Eigenschaften wollte Linus unbedingt haben, konnte sie aber nicht finden? Unterstützung der verteilten Entwicklung Die»verteilte Entwicklung«besitzt viele Facetten, und Linus wollte ein neues VCS haben, das die meisten von ihnen abdeckte. Es sollte sowohl parallele als auch unabhängige und gleichzeitige Entwicklung in privaten Repositories erlauben, ohne dass ständig eine Synchronisation mit einem zentralen Repository nötig wäre, die einen Entwicklungsengpass bilden könnte. Es müsste mehrere Entwickler an mehreren Orten zulassen, selbst wenn einige von ihnen zeitweise offline wären. Tausende von Entwicklern Es reicht nicht, nur ein verteiltes Entwicklungsmodell zu haben. Linus wusste, dass an jeder Linux-Version Tausende von Entwicklern mitarbeiteten, sodass jedes neue VCS mit einer großen Anzahl von Entwicklern zurechtkommen musste ob sie nun an denselben oder an unterschiedlichen Teilen eines gemeinsamen Projekts arbeiteten. Und das neue VCS musste dazu in der Lage sein, ihre gesamte Arbeit zuverlässig zu integrieren. 2 Kapitel 1: Einführung

8 Schnelle und effiziente Ausführung Linus wollte das neue VCS unbedingt schnell und effizient haben. Um die schiere Masse von Update-Operationen zu unterstützen, die allein am Linux-Kernel vorgenommen werden würden, müssten sowohl die einzelnen Update-Operationen als auch die Operationen zur Netzwerkübertragung sehr schnell sein. Um Platz und damit Übertragungszeit zu sparen, würden Komprimierungs- und»delta«-techniken benötigt werden. Der Einsatz eines verteilten Modells anstelle eines zentralisierten Modells würde sicherstellen, dass die tägliche Entwicklung nicht durch die Netzwerklatenz behindert wird. Integrität und Vertrauen bewahren Da es sich bei Git um ein verteiltes Revisionskontrollsystem handelt, ist es unerlässlich, die absolute Sicherheit zu haben, dass die Integrität der Daten gewahrt und nicht in irgendeiner Weise verletzt wird. Woher wissen Sie, dass die Daten beim Übergang von einem Entwickler oder einem Repository zum nächsten nicht verändert wurden? Und woher wissen Sie, dass die Daten in einem Git-Repository wirklich das sind, was sie zu sein vorgeben? Git benutzt eine gebräuchliche kryptographische Hash-Funktion namens Secure Hash Function (SHA1), um Objekte in seiner Datenbank zu benennen und zu identifizieren. Diese Funktion bietet vielleicht keinen absoluten Schutz, hat sich aber in der Praxis als solide genug erwiesen, um die Integrität und das Vertrauen für alle verteilten Repositories von Git zu sichern. Verantwortlichkeit erzwingen Einer der wesentlichen Aspekte bei einem Versionskontrollsystem besteht darin zu wissen, wer die Dateien geändert hat und weshalb dies geschehen ist (falls sich das überhaupt sagen lässt). Git erzwingt bei jedem Commit (Änderungsbestätigung), das eine Datei ändert, einen Protokolleintrag in einem Änderungslog. Welche Informationen in diesem Änderungslog gespeichert werden, hängt von den einzelnen Entwicklern, den Projektanforderungen, dem Management, den vereinbarten Konventionen usw. ab. Git sorgt dafür, dass Dateien, die der Versionskontrolle unterliegen, nicht mysteriöserweise geändert werden, da sich die Verantwortlichkeit für alle Änderungen nachverfolgen lässt. Unveränderbarkeit Gits Repository-Datenbank enthält Datenobjekte, die unveränderbar sind. Das bedeutet: Sobald sie erzeugt und in der Datenbank abgelegt wurden, können sie nicht mehr verändert werden. Man kann sie natürlich auf andere Weise neu anlegen, die Originaldaten lassen sich jedoch nicht folgenlos ändern. Das Design der Git- Datenbank bewirkt, dass auch die gesamte History, die in der Versionskontrolldatenbank gespeichert ist, unveränderbar ist. Die Benutzung unveränderbarer Objekte bringt mehrere Vorteile mit sich, wie etwa die Möglichkeit, schnelle Vergleiche durchzuführen. Die Geburt von Git 3

9 Atomare Transaktionen Bei atomaren Transaktionen werden unterschiedliche, aber verwandte Änderungen entweder zusammen oder gar nicht ausgeführt. Diese Eigenschaft sorgt dafür, dass die Versionskontrolldatenbank nicht in einem teilweise geänderten (und damit möglicherweise unzulässigen) Zustand hinterlassen wird, wenn ein Update oder Commit durchgeführt wird. Git implementiert atomare Transaktionen, indem es vollständige, diskrete Repository-Zustände aufzeichnet, die nicht in einzelne oder kleinere Zustandsänderungen unterteilt werden können. Unterstützung und Förderung der verzweigten Entwicklung Fast alle VCS können unterschiedliche Entwicklungsstammbäume innerhalb eines einzigen Projekts benennen. So könnte z. B. eine Folge von Codeänderungen mit»entwicklung«bezeichnet werden, während eine andere»test«heißt. Jedes Versionskontrollsystem ist außerdem in der Lage, eine einzelne Entwicklungslinie in mehrere Entwicklungslinien aufzuteilen und dann die verschiedenen Fäden wieder zu vereinigen oder zusammenzuführen. Genau wie die meisten VCS nennt Git eine Entwicklungslinie Zweig (engl. branch) und weist jedem Zweig einen Namen zu. Neben dem Verzweigen gibt es das Vereinigen. Linus wollte nicht nur das Verzweigen vereinfachen, um alternative Linien zu fördern, sondern auch das Vereinigen dieser Zweige sollte leicht vonstatten gehen. Da das Vereinigen von Zweigen in anderen Versionskontrollsystemen oft eine leidige und schwierige Operation war, sollte es in Git auf jeden Fall sauber, schnell und leicht gehen. Vollständige Repositories Damit einzelne Entwickler nicht einen zentralisierten Repository-Server nach historischen Revisionsinformationen abfragen müssen, war es entscheidend, dass jedes Repository für jede Datei eine vollständige Kopie aller vergangenen Revisionen erhält. Ein sauberes internes Design Ein Endanwender mag sich über ein sauberes internes Design vielleicht nicht sonderlich viele Gedanken machen, für Linus und entsprechend auch für andere Git-Entwickler war es dagegen natürlich sehr wichtig. Das Objektmodell von Git weist einfache Strukturen auf, die grundlegende Konzepte für die Rohdaten, die Verzeichnisstruktur, das Aufzeichnen von Änderungen usw. abdecken. Dieses Objektmodell in Verbindung mit einer global eindeutigen Identifizierungstechnik erlaubt im Ergebnis ein sehr sauberes Datenmodell, das in einer verteilten Entwicklungsumgebung verwaltet werden kann. Frei wie in Freiheit (oder in Freibier) Muss man mehr sagen? Da es offensichtlich Bedarf für ein neues VCS gab, setzten sich viele talentierte Softwareprogrammierer zusammen und schufen Git. Es entstand also aus reiner Notwendigkeit! 4 Kapitel 1: Einführung

10 Die Vorgeschichte Der Versuch, die Geschichte der Versionskontrollsysteme vollständig darzulegen, würde den Rahmen dieses Buches sprengen. Es gibt jedoch einige wegweisende, innovative Systeme, die die Grundlage bildeten oder direkt zur Entwicklung von Git führten. (Dieser Abschnitt soll nur punktuell zeigen, wann neue Funktionen eingeführt oder in der Free- Software-Gemeinschaft populär wurden.) Das Source Code Control System (SCCS) war eines der ursprünglichen Systeme unter Unix. Es wurde in den frühen 70er Jahren des 20. Jahrhunderts von M. J. Rochkind entwickelt. 1 Dabei handelt es sich wohl um das erste VCS, das auf einem Unix-System verfügbar war. Der zentrale Speicher, den das SCCS bereitstellte, wurde als»repository«bezeichnet, und dieses grundlegende Konzept gibt es bis heute. SCCS bot darüber hinaus ein einfaches Locking-Modell, um die Entwicklung zu serialisieren. Musste ein Entwickler Dateien ausführen und ein Programm testen, dann checkte er sie ohne Sperren aus. Um eine Datei jedoch zu bearbeiten, musste er sie mit einer Sperre auschecken (diese Konvention wird vom Unix-Dateisystem erzwungen). Nach Beendigung der Arbeit checkte er die Datei wieder im Repository ein und entfernte die Sperre. In den frühen 80er Jahren des 20. Jahrhunderts stellte Walter Tichy das Revision Control System (RCS) 2 vor. RCS führte Vorwärts- und Rückwärts-Deltas ein, um unterschiedliche Dateirevisionen effizient speichern zu können. Das Concurrent Version System (CVS), 1986 von Dick Grune entworfen und erstmals implementiert, vier Jahre später dann von Berliner et al. neugeschrieben, erweiterte und modifizierte das RCS-Modell, und das mit großem Erfolg. CVS wurde sehr beliebt und war über eine lange Zeit der De-facto-Standard in der Open Source-Gemeinde. CVS wies gegenüber RCS mehrere Vorteile auf, darunter eine verteilte Entwicklung und Repository-weite Änderungssätze für ganze»module«. Außerdem führte CVS ein neues Paradigma für die Sperren (Locks) ein. Während frühere Systeme verlangt hatten, dass der Entwickler jede Datei sperrte, bevor er sie änderte, und die Entwickler dann entsprechend warten mussten, bis sie an der Reihe waren, gab CVS jedem Entwickler die Berechtigung, auf seine private Arbeitskopie zu schreiben. Änderungen von unterschiedlichen Entwicklern konnten später automatisch vom CVS zusammengeführt werden, es sei denn, zwei Entwickler versuchten, dieselbe Zeile zu ändern. In diesem Fall wurde der Konflikt gekennzeichnet, und die Entwickler mussten eine Lösung finden. Die neuen Regeln für die Sperren erlaubten es unterschiedlichen Entwicklern, gleichzeitig und parallel am Code zu arbeiten. 1»The Source Code Control System«, IEEE Transactions on Software Engineering 1(4) (1975): »RCS A System for Version Control«, Software Practice and Experience 15 (7) (Juli 1985): Die Vorgeschichte 5

11 Index Symbole # (Hash-Zeichen) Kommentar 63, 138, 185 $GIT_DIR-Variable 19, 75 * (Asterisk) Globbing 64 show-branch (Pluszeichen) Diff 115 Merges 141 Refspec 200 show-branch (Minuszeichen) 21 Diff (doppelter Bindestrich) 21. (Punkt) 22, 99.. (doppelte Punkte) 85, 124, 260 (dreifache Punkte) 89, 126 / (Schrägstrich) 64, 99 > (rechts) 144 ^ (Zirkumflex) 76 ~ (Tilde) 76 Numerisch -3- oder --3way-Optionen (git am-befehl) 271 A Abbildung 69 Abbrechen Merges abbrev-commit-option (git log-befehl) 79 abgesonderter HEAD 323 bisect-modus 91 Zweige 111, 197 Abkürzungen Commit-IDs 73 Zirkumflexe und Tilden 77 Abnehmer Upstream- und Downstream abort-option (git rebase-befehl) abort-option (git am-befehl) 270 Abrufen git fetch-befehl 201, 218 vor dem Bestätigen 313 Abrufschritt entfernte Repositories 211 absolute Commit-Namen Commit-IDs 73 add git add-befehl 22, 66, 146 aktuelles Repository Definition 196 Aliase 278 konfigurieren 30 --all-option (git commit-befehl) 56 Already up-to-date-merges 151 am git am-befehl 267, 284 Ambivalenz hinsichtlich des Verlaufs amend-option (git commit-befehl) 178 Änderungen in unterschiedlichen Zweigen zusammenführen 108 Projektänderungen nach oben übermitteln 298 unbestätigte

12 Änderungsmengen atomare Änderungsmengen 72 anonymer Lesezugriff 228 anonymer Schreibzugriff 231 Anschauen Commits 25, 78 Commit-Unterschiede 26 Konfigurationsdateien 30 Zweige 103 Anwenden git apply-befehl 267 Patches 267 -a-option (git commit-befehl) 56 -a-option (git diff-befehl) 120 applypatch-msg-hook 284 Arbeitsbereich mehrere Repositories 245 Arbeitsverzeichnis Definition 22 Asterisk (siehe *) atomare Änderungsmengen Commits 72 atomare Transaktionen von VCS 4 Auflisten Zweignamen 102 Aufspalten Projekte 250 Austauschen Commits author-option (git commit-befehl) authors-file-option (git svn-befehl) 311 Autorenname Fehlermeldung 24 autoritative Repositories erzeugen 202 B Backups Peer-to-Peer 240 Backup-Strategien 1 --bare-option (git clone-befehl) 195, 203 Bare-Repositories Definition base-option (git diff-befehl) 141 Basisdateien Diffs 271 Bäume 34 Baumobjekte und Diffs 116 benutzen 43 Bilder von 38 Hierarchien 46 über 34 Bearbeiten Konfiguration manuell bearbeiten 224 Bekommen Repository-Updates 209 Benutzeridentifikation SVN verglichen mit Git 311 Bereiche Commits 85, 124, 260 Verlauf 79 Bereitstellen Änderungen an Index 35 Dateien 56 über 51 Bilder von entfernten Repository-Operationen 214 binärer Merge-Treiber 158 Bindestrich (siehe - (Minuszeichen)) bisect git bisect-befehl 90, 160 bisect replay git bisect replay-befehl 93 bisect visualize git bisect visualize-befehl 94 BitKeeper 2, 6 blame git blame-befehl 95, 160 Blobs benutzen 42 Bilder von 38 über 34 -b-option (git checkout-befehl) 110 C --cached-option (git diff-befehl) 52, cached-option (git rm-befehl) 59 Caches git-svn-cache 324 cat-befehl 30 Checkouts git checkout-befehl 105, 145, 176 Teilprojekte mit Skripten 299 teilweise Checkouts 290 Zweige 105 check-ref-format git check-ref-format-befehl 100 cherry-pick git cherry-pick-befehl Index

13 --color-option (git diff-befehl) 120 Commit-Autor konfigurieren 24 Commit-IDs 73, 317 absolute 73 relative 76 symbolische 74 Commit-Log-Meldungen schreiben 58 commit-msg-hooks 284 Commits 71 anschauen 25 atomare Änderungsmengen 72 ausführen 24 austauschen 253 benutzen 47 Bereiche 85, 124 Bereiche und Merges 260 git commit-befehl 56, 178 git diff-befehl 117 Graphen 81 Hooks 283 identifizieren 73 Index 52 Linearisierung 264 Reihenfolge in git diff-befehl 126 Schritte in 68 Squash-Commits 160 suchen 90 svn rebase 315 über 35 verändern 163 Verlauf 78 verteilte Versionskontrolle 238 vor dem Bestätigen 313 zwischen Upstream- und Downstream-Repositories übertragen 243 Commit-Unterschiede anschauen 26 Concurrent Version System (CVS) 5, 49, 291, 293 config git config-befehl 223 Content-Tracking 36 --continue-option (git rebase-befehl) 182 Criss-Cross-Merges 151, 154 CVS (Concurrent Version System) 5, 49, 291, 293 Cygwin-Git über 13 unter Windows installieren 14 D Daemonen git-daemon 228 HTTP-Daemon 230 daemon-run git-daemon-run 10 DAG (gerichteter azyklischer Graph, directed acyclic graph) Ambivalenz hinsichtlich des Verlaufs 239 Gitlinks 301 topologische Sortierung 263 über 81 Dateien Basisdateien und Diffs 271 benutzen 43 bereitstellen 56 Dateiinhalt (siehe Blobs) entfernen 27, 58 Funktionen verschieben zwischen 72.gitignore-Dateien 63 Git-Objektmodell 65 Globbing 63 Indexdatei 51 Klassifikationen 52 Konfigurationsdateien 28 Lokalisieren konfliktbehafteter 139 Namen des Git-Verzeichnisses 75 Pfadnamen 37 umbenennen 27, 62 verfolgen 37, 54 zu Repositories hinzufügen 22 Datenstrukturen (siehe auch Index) Debian Linux-Distributionen Git installieren 9 Pakete auf Debian/Ubuntu-Systemen 9 degenerierte Merges 151 Depot-Verzeichnis 202 Diffs 115 Basisdateien 271 Commit-Bereiche 124 einfaches git diff-beispiel 120 git diff-befehl 26, 52, 81, 116, 137, 140, 141, 255, 297 Treiber 158 zwischen Dateien nachvollziehen 62 Digests SHA1-Hashes 45 doppelte Punkte (..) 85, 124, 260 doppelter Bindestrich (--) 21 Index 329

14 -d-option (git branch-befehl) 112 Downstream-Abnehmer 244 Downstream-Flüsse verteilte Repositories 241 Downstream-Produzenten 244 Downstream-Repositories zwischen Upstream- und Downstream-Repositories übertragen 243 dreifache Punkte ( ) 89, 126 Dreifach-Merges 271 E Editoren Commit-Log-Meldungen 58 Umgebungsvariablen 23 Effizienz SHA1 71 von VCS 3 Eltern-Commits benutzen 48 Definition 76 git- 10 Patches 264, 274 SMTP, offene Relay-Server 265 Entfernen Dateien 58 Dateien in Repositories 27 entfernte Repositories 33, 193 Bare-Repositories und git push-befehl 224 Definition 196 entfernte Zweige hinzufügen und löschen 221 mit Bildern visualisieren 214 Repositories referenzieren 198 über 194 veröffentlichen 226 entfernte Tracking-Zweige 74, 103, 197 entferntes Update 205 Entwickler hinzufügen 207 Entwicklerrolle verteilte Repositories 241 Entwicklungs-Repositories Definition 194 Erreichbarkeit Graphen 86 Erzeugen autoritative Repositories 202 Hooks 281 Zweige 101, 110 /etc/gitconfig-datei 29 F Fast-Forward-Merges 151, 217 Fedora Linux-Distributionen Git installieren 10 Fehlermeldungen 24 Festplattenplatz in SVN sparen 129 FETCH_HEAD-Symref 75 find git find-befehl 41 --first-parent-option (git log-befehl 160 flüchtige Dateien 53 -f-option (git checkout-befehl) 108 -f-option (git push-befehl) 218 -f-option (git remote update-befehl) 205 -f-option (git rm-befehl) 60 format-patch git format-patch-befehl 255, 266, 267 Freedesktop.org 236 freigegebene Repositories 233, 320 Funktionen von einer Datei in die andere verschieben 72 G Generieren Patches 255 Gentoo Linux-Distribution Git installieren 10 gerichteter azyklischer Graph (siehe DAG) Geschichte von Git 2 Git benennen 7 Diffs ableiten im Vergleich zu Subversion 128 grundlegende Konzepte 33, 41 kurze Einführung 21 Verlauf 2 git add-befehl 22, 54, 66, 146 git am-befehl 267, 284 git apply-befehl 267 Git Bash-Befehl 16 git bisect replay-befehl 93 git bisect visualize-befehl 94 git bisect-befehl 90, 160 git blame-befehl 95, 160 git branch-befehl 102, 112 git checkout-befehl 105, 145, 176 git check-ref-format-befehl 100 git cherry-pick-befehl 174 git clone-befehl 28, 34, 195, 203, 214, 277, 299, Index

15 git commit-befehl 48, 52, 56, 68, 178, 283 git config-befehl 24, 29, 223 git diff-befehl 26, 52, 81, 115, 137, 140, 141, 255, 297 git fetch-befehl 201, 218 git find-befehl 41 git format-patch-befehl 255, 266, 267 Git für eine Open-Source-Version kompilieren 12 git hash-object-befehl 55 git init-befehl 22, 41 Git installieren 9 mithilfe der Quellversionen 11 git log Konflikte 143 git log-befehl 25, 78, 86, 96, 124, 134, 143, 147 git ls-files-befehl 55, 139, 145 git merge-base-befehl 85, 100, 150 git merge-befehl 133, 314 git mv-befehl 27, 60 git pull-befehl 157, 211, 254, 294, 295, 322 git push-befehl 201, 206, 217, 218, 220, 224, 285 git rebase-befehl 180, 211, 238, 314 git reflog-befehl 114 git remote-befehl 196, 204, 222 git reset-befehl 166, 176 git revert-befehl 176 git rev-list-befehl 89, 261 git rev-parse-befehl 75, 78, 170, 207 git rm-befehl 27, 58 git send- -befehl 264, 266 git show-befehl 25, 48, 81, 147 git show-branch-befehl 26, 78, 103 git show-ref-befehl 201 git status-befehl 53, 139 git svn clone-befehl 310 git svn dcommit-befehl 321 git svn rebase-befehl 316 git svn-befehl 316, 324 git symbolic-ref-befehl 76 git tag-befehl 49 git write-tree-befehl 44, 47.git/config-Datei 29 git-befehl 19 git-daemon 228 git-daemon-run 10.git-Dateien 41 Dateien.git-Dateien 41.git-Dateierweiterung 75 Git-eigenes Protokoll 199 git- 10.gitignore verglichen mit svn ignore 323.gitignore-Dateien 54, 63 gitk-befehl 84, 160 Gitlinks Projekte kombinieren 301 Git-Objektmodell Bedeutung 4 Merges 158 über 65 git-svn 9 git-svn-cache 324 Git-Verzeichnis Namen 75.git-Verzeichnis 41 gitweb 9 global eindeutige Identifikatoren SHA global-option (git config-befehl) 29 Globbing 63 Graphen Commit-Graphen 81 Erreichbarkeit 86 topologische Sortierung graph-option (git log-befehl) 134 H --hard-option (git reset-befehl) 166, 177 hash-object git hash-object-befehl 55 Hash-Werte benutzen 42 SHA1 43, 44, 73 Hash-Zeichen (siehe #) HEAD (siehe abgesonderter HEAD) HEAD-Symref 75 HEAD-Zweige, abgesonderte 111»Hello World«-Beispiel 42, 46, 146 Herausgeber Rollen und Datenflüsse 244 Hierarchien Bäume 46 Hinzufügen entfernte Zweige 221 Entwickler 207 git add-befehl benutzen 54 Hooks 277 Arten von 282 installieren 279 Index 331

16 HTTP verglichen mit dem Git-eigenen Übertragungsprotokoll 253 HTTP- und HTTPS-URLs 199 HTTP-Daemon 230 I Identifizieren Commits 73 Identifizieren von Commits relative 76 IDs (siehe auch Commit-IDs) SHA ignore-all-space-option (git diff-befehl) 120 ignorierte Dateien 53 Importieren Code in Projekte 292 Teilprojekte mit git pull-befehl 294 Index 51 Dateiklassifikationen 52 Definition 34 git add-befehl 54 git commit-befehl 56 git rm-befehl 58 schmutziger 132 über 35, 52 Überwachen von Konflikten 145 inetd 229 Inhalt im Vergleich mit Pfadnamen 37 inhaltsadressierbare Namen 36 init git init-befehl 22, 41 Installieren von Git als Quellversion 11 unter Linux 9 unter Windows 13 --interactive-option (git add-befehl) 56 --interactive-option (git commit-befehl) 56 -i-option (git rebase-befehl) 183 K KDE-Projekt 291 Klassifikationen Dateien 52 Klone Definition 193 git clone-befehl 28, 34, 195, 203, 214, 277, 299, 303 Zweige 309, 318 Kollisionen SHA1 43 Kombinieren Projekte 289 Kommandozeile benutzen 19 kommentierte Tags Definition 48 Konfigurationsdateien 28 Konfigurieren Aliase 30 Commit-Autor 24 entfernte Repositories 222 Konfigurationswerte beim Klonen 34 konfliktbehaftete Dateien lokalisieren 139 Konflikte Merges 134, 219 kontrollierter Zugriff Repositories 227 Kopieren Teilprojekte importieren 293 Kreise 34 Bilder von 38 Kurzform für Optionen (git-befehl) 20 L Langform für Optionen (git-befehl) 20 Lebensdauer Zweige 102 left (<) 144 -left-right-option(git log-befehl) 144 leichte Tags Definition 48 Lesezugriff, anonymer 228 Linearisierung Commits 190, 239, 264, 274 Linux Git auf Binärdistributionen installieren 9 Linux Kernel-Projekt 2, 3, 7, 156, 235, 236, 240, 250, 252, 289 log git log-befehl 25, 78, 86, 96, 124, 134, 147 Logmeldungen 23 Logs git log 78, 143 lokales Repository Definition 196 -l-option (git config-befehl) Index

17 Löschen remote Zweige 221 Zweige 112 ls-files git ls-files-befehl 55, 139, 145 M Mail Transfer Agent (MTA) 266 Mail User Agent (MUA) 264 Maintainer-Rolle 234, 241 master-zweig 99, 100 mehrere Repositories 245 Arbeitsbereich 245 benutzen 248 in ein anderes Upstream-Repository konvertieren 246 Projekte aufspalten 250 Repositories starten 245 Meldungen Commit-Logmeldungen 58 Fehlermeldungen 24 Logmeldungen 23 Mercurial 6 MERGE_HEAD-Symref 76 merge-base git merge-base-befehl 150 Merge-Commits 134, 138, 147, 151, 176, 239, 259, 296, 316, 322, 323 Commit-Graphen 84 degenerierte Merges 151 git add 137 gitk 85 Graphen 84 in unterschiedliche Zweige zusammenführen 109 Konfliktauflösung 147 Merges abbrechen oder neustarten 148 Octopus-Merges 154 Patches 260 Push und Pull 243 relative Commit-Namen 76 Verläufe zusammenführen 219 Zweige anschauen merge-option (git log-befehl) 144 Merges 131 Änderungen in unterschiedliche Zweige zusammenführen 108 Beispiele 132 Dreifach-Merges 271 git svn-befehl 316 Git-Objektmodell 158 Konflikte 134, 219 Strategien für 148 Subversion 321 svn dcommit 322 und Zweige 101 verglichen mit Patches 274 verglichen mit Rebase 187, 315 Verlauf 219 Merges neustarten 153 (siehe auch git bisect-befehl) Merge-Schritt entfernte Repositories 212 Merge-Treiber 157 Metadaten in Objekttypen 34 Minuszeichen (siehe -) --mixed-option (git reset-befehl) 166 Monotone 6 --M-Option (git diff-befehl) 120 -m-option (git checkout-befehl) more-option (git show-branch-befehl) 26, 104 msysgit über 13 unter Windows installieren 14 MTA (Mail Transfer Agent) 266 MUA (Mail User Agent) 264 Muster.gitignore-Muster und -Dateinamen 63 mutt mbox-mailordner importieren 265 mv git mv-befehl 27 git mv-befehl benutzen 60 N Namen 7 absolute Commit-Namen 73 Commits 73 entfernte Tracking-Zweige 197 Fehlermeldung wegen Autorennamen 24 Git 7 Git-Verzeichnis 75 inhaltsadressierbare Namen 36 Pfadnamen verglichen mit Inhalt 37 relative Commit-Namen 76 Revisionen 27 Symrefs 74 Tags 74 Zweige 76, 99, 100, 102 Index 333

18 nicht verfolgte Dateien 53 Nicht-Fast-Forward-Push-Problem no-ff-option (git svn dcommit-befehl) 151, 322 normale Merges 153 O -o Verzeichnis-Option (git format-patch-befehl) 266 oberste Commits ändern 178 Objekte benutzen 42 die zusammenarbeiten 38 Git-Objektmodell 65, 158 (siehe auch Blobs) Typen 34 vergleichen 46 Typen von Objekten 34 Objektspeicher 34 Definition 34 Inhaltsüberwachung 37 über 36 Octopus-Merges onto-option (git rebase-befehl) 181 Optionen git-befehl 20 ORIG_HEAD-Symref 75 --origin-option (git clone-befehl) 196 Ours-Merges 155, ours-option (git diff-befehl) 141 P Packard, Keith über xorg und Git 237 Pakete andere Linux-Distributionen 10 Patches 253 anwenden 267 Aufgabe 254 Befehle zum Austauschen von Daten 253 generieren 255 Hooks 284 per verschicken 264 Rebase 315 schlechte Patches 274 verglichen mit Merges 274 Peer-to-Peer-Backups 240 Peer-to-Peer-Modell 6, 224, 234, 247 mittels Patches 254 Pfadbegrenzung git diff-befehl 126 Pfadnamen git mv 61 verglichen mit Inhalt 37 Pfeile zwischen Commits 40 Pförtner-Repositories 319 Pickaxe Definition 96 git diff-befehl 128 Pluszeichen (siehe +) -p-option (git log-befehl) 144 post-applypatch-hook 285 post-checkout-hook 286 post-commit-hook 284 Post-Hooks Definition 277 post-merge-hook 287 post-receive-hook 286 post-update-hook 286 PowerPC 247 Prä-Hooks Definition 277 pre-applypatch-hook 285 pre-auto-gc-hook 287 pre-commit-hook prefix=svn/-option (git svn-befehl) 319 pre-rebase-hook 286 pre-receive-hook preserve-merges-option (git rebase-befehl) pretty-option (git log-befehl) 79 --pretty-option (git show-befehl) 48 Projekte aufspalten 250 Code importieren 292 kombinieren 289 Pull git pull-befehl 211, 294 git svn-befehl 316 Punkt (.) 22, 99 Push git push-befehl 201, 206, 217, 218, 220, 224 Hooks 285 Q Quellversionen Git installieren Index

19 R Raute (siehe # (Hash-Zeichen)) RCS (Revision Control System) 5 Definition 1 Rebase durch git svn rebase bestätigen 315 git rebase-befehl 180, 238 verglichen mit Merge rebase-option (git pull-befehl) 211 Rebase-Schritt entfernte Repositories 212 rechts (>) 144 Referenzieren Repositories 198 Reflog 195 git reflog-befehl 114, 172 Refs und Symrefs (symbolische Referenzen) 74 Refspecs Syntax 222 über 200 Zweige zusammenführen 213 rekursive Merges 153, 154, 156 relative Commit-Namen 76 Remote Beispiel 202 git remote-befehl 196, 204, 222 Konfiguration 222 Origin 204 Remote-Origin Depot-Verzeichnis 202 Repositories Bare-Repositories 194 Dateien entfernen und umbenennen 27 Dateien hinzufügen 22 Entwicklungs-Repositories 194 freigegebene Repositories 233, 320 Funktionsweise 21 Pförtner-Repositories 319 Sammlungen von Hooks replizieren 278 Struktur 233 über 33, 194 veröffentlichen 226 Vollständigkeit von 4 Repositories (siehe auch Klone) reset git reset-befehl 166, 176 Resolve-Merges 153, 156 revert git revert-befehl 176 Revision Control System (RCS) 5 Definition 1 Revisionen Namen 27 rev-list git rev-list-befehl 261 rev-parse git rev-parse-befehl 75, 78, 170, 207 rm git rm-befehl 27, 58 --root-option (git format-patch-befehl) 262 -r-option (git diff-befehl) 116 rsync-protokoll 200 S -s subtree-option (git pull-befehl) 297 SCCS (Source Code Control System) 5 schlechte Patches 274 schmutziges Arbeitsverzeichnis oder Index 132 Schnappschüsse 35, 71, 105, 129, 236 Schrägstrich (/) 64, 99 Schreiben Commit-Log-Meldungen 58 Schreibzugriff, anonymer 231 SCM (Source Code Manager) Definition 1 send- git send- -befehl 264, 266 Konfigurationsoptionen 265 SHA1 (Secure Hash Function) 3 benutzen 44 Dateien ergänzen 56 Effizienz 71 Eindeutigkeit und Kollisionen 43 Werte 36 show git show-befehl 25, 48, 81, 147 show-branch git show-branch-befehl 26, 78, 103 Skalieren von VCS 2 Zweignamen und 99 --skip-option (git rebase-befehl) 183 Skripten Hook-Skripten 278, 279 Teilprojekte auschecken 299 SMTP Konfigurationsoptionen 265 offene Relayserver soft-option (git reset-befehl) 166 Index 335

20 -S-Option (git diff-befehl) 128 -S-Option (git log-befehl) 98, 128 (siehe auch Pickaxe) -s-option (git ls-files-befehl) 145 Source Code Control System (SCCS) 5 Source Code Manager (SCM) Definition 1 Sperren CVS 5 --squash-option (git merge-befehl, git pull- Befehle) 160 Squash-Merges 159 Startpunkte Repositories 245 Zweige 85 --stat-option (git log-befehl, git diff-befehl) 80 Status Dateien 54 git status-befehl 53, stdlayout-option (git svn-befehl) 319 Suchen Commits 90 SVN (Subversion) 6 Ableiten von Diffs im Vergleich zu Git 128 git svn-befehl 316, 324 mit Git benutzen 309 Umbenennungen überwachen 62 svn clone git svn clone-befehl 310 svn dcommit git svn dcommit-befehl 321 svn rebase git svn rebase-befehl 316 svn:ignore verglichen mit.gitignore 323 symbolic-ref git symbolic-ref-befehl 76 symmetrische Differenzen 89 Symrefs (symbolische Referenzen) und Refs 74 T Tags benutzen 48 Bilder von 38 Namen 74 über 35 verglichen mit Zweigen 98 Teilbäume Merges 155, 157 Teilprojekte durch Kopieren importieren 293 mit git pull-befehl importieren 294 mit Skripten auschecken 299 teilweise Checkouts 290 temporäre Dateien 53 Text-Merge-Treiber theirs-option (git diff-befehl) 141 Tilde (~) 76 Topic-Zweige Definition 98 topologische Sortierung git format-patch-befehl 263 Patches 263 Torvalds, Linus Git herstellen 1 über Backups 240 über den Index 52 über Forks 252 Tracking-Zweige entfernte Repositories 194 Treiber Diff-Treiber 158 Merge-Treiber 157 U Übermitteln Projektänderungen upstream 298 Übertragungsprotokolle 253 Überwachen Dateien 52, 54 Dateiumbenennungen 62 Inhalt 36 Konflikte 144 Zweige 197 Ubuntu Linux Git installieren 9 Umbenennen Dateien 27, 62 überwachen 63 Umgebungsvariablen Editoren 23 unbestätigte Änderungen Zweige auschecken 107 Uniform Resource Locator (URL) entfernte Repositories 198 Union-Merge-Treiber 158 Unterbefehle git-befehl Index

21 Untermodule 301 über 289 Untersuchen von Konflikten 140 Unveränderbarkeit 3 -u-option (git diff-befehl) 115 Update-Hooks 286 Updates Repositories 209 Upstream-Abnehmer 244 Upstream-Flüsse verteilte Repositories 241 Upstream-Herausgeber 244 Upstream-Repositories in andere Upstream-Repositories umwandeln 246 zwischen Upstream- und Downstream-Repositories übertragen 243 URL (Uniform Resource Locator) entfernte Repositories 198 V VCS (Version Control System) Beschränkungen 2 Definition 1 Verändern Commits 163 vereinheitlichte Diffs 115 Vergleichen Objekte 46 Verlauf abrufen 218 alternativer 165, 216 Bereich 79 Commits 78 öffentlichen Verlauf ändern 237 verteilte Versionskontrolle 239 zusammenführen 219 Zweige abrufen und zusammenführen 275 Veröffentlichen Repositories 226 Zweige 101 Verschieben (Push) git svn-befehl 316 verteilte Entwicklung 2 verteilte Repositories 33, 237 leben mit 237 Maintainer- und Entwicklerrollen 241 Struktur 234 Upstream- und Downstream-Flüsse 241 Veröffentlichen und verteilte Versionskontrolle 238 Verzeichnisse Depot-Verzeichnis 202.git-Verzeichnis 41 schmutzige 132 Struktur 38 Vorwärtsportierung 181, 212 W Werte SHA1 36 Wildcards Globbing 63 Zweignamen 99 Windows Git installieren 13 -w-option (git diff-befehl) 120 write-tree git write-tree-befehl 44, 47 X X.org-Projekt 236 xinetd 229 Z Zirkumflex (^) 76 Zugriff anonymer Lesezugriff 228 anonymer Schreibzugriff 231 kontrollierter Zugriff 227 Zweige 97 anschauen 103 Aufgabe 97 auschecken 105 benutzen 100 Bilder von 39 entfernte Tracking-Zweige 197 entfernte Zweige hinzufügen und löschen 221 erzeugen 101 git branch-befehl 102 git show-branch-befehl 26 git svn-befehl 316 in VCS 4 klonen 309, 318 Lebensdauer 102 löschen 112 mit komplexen Verläufen abrufen und zusammenführen 275 Index 337

22 Namen 76, 99, 102 Startpunkte 85 Tracking 194, 197, 205 und Merges 101 veröffentlichen 101 wiederherstellen 114 zusammenführen Index