Sujeevan Vijayakumaran

Versionsverwaltung mit Git

Bibliografische Information der Deutschen NationalbibliothekDie 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-95845-227-51. Auflage 2016

www.mitp.deE-Mail: mitp-verlag@sigloch.deTelefon: +49 7953 / 7189 - 079Telefax: +49 7953 / 7189 - 082

© 2016 mitp Verlags GmbH & Co. KG, Frechen

Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. JedeVerwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohneZustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Ver-vielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung undVerarbeitung in elektronischen Systemen.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw.in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu derAnnahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt wer-den dürften.

Lektorat: Sabine SchulzSprachkorrektorat: Petra Heubach-ErdmannCoverbild: Sujeevan VijayakumaranSatz: III-satz, Husby, www.drei-satz.de

5

Inhaltsverzeichnis

Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.1 Versionsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.1.1 Lokale Versionsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.1.2 Zentrale Versionsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 191.1.3 Verteilte Versionsverwaltung. . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.2 Geschichtliches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Die Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2 Das erste Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3 Git-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4 Der erste Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.1 Versionierte Dateien mit »git mv« verschieben . . . . . . . . . . . 442.5 Änderungen rückgängig machen mit Reset und Revert . . . . . . . . . . 44

2.5.1 Revert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.5.2 Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.6 Git mit GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.6.1 Commits mit Git GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.7 Wie Git arbeitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.8 Git-Hilfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3 Arbeiten mit Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.1 Allgemeines zum Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.2 Branches anlegen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.3 Branches mergen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.4 Merge-Konflikte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.5 Mergetools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.6 Merge-Strategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.6.1 resolve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Inhaltsverzeichnis

6

3.6.2 recursive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.6.3 octopus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.6.4 ours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.6.5 subtree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.7 Rebasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.8 Stash und Clean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.8.1 Den Arbeitsordner säubern . . . . . . . . . . . . . . . . . . . . . . . . . . . 893.8.2 Dateien ignorieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4 Verteilte Repositories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.1 Projekt mit einem Remote-Repository . . . . . . . . . . . . . . . . . . . . . . . . . 964.2 Branch-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034.3 Tracking-Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.4 Projekt mit drei Remote-Repositories . . . . . . . . . . . . . . . . . . . . . . . . . 1084.5 Der Workflow mit drei Repositories. . . . . . . . . . . . . . . . . . . . . . . . . . . 1104.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5 Git-Hosting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155.1 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5.1.1 Repository anlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175.1.2 SSH-Keys anlegen und hinzufügen . . . . . . . . . . . . . . . . . . . . 1205.1.3 SSH-Agent konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225.1.4 Lokales Git-Repository konfigurieren . . . . . . . . . . . . . . . . . . . 1245.1.5 Repository klonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.1.6 Der GitHub-Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265.1.7 GitHub-Repositories um externe Tools erweitern . . . . . . . . . 140

5.2 GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415.2.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415.2.2 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

5.3 gitolite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1455.4 Weitere Git-Hosting-Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1465.5 3rd-Party-Tools für Continuous Integration . . . . . . . . . . . . . . . . . . . . 146

5.5.1 Der Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1475.5.2 Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485.5.3 Travis-CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535.5.4 GitLab-CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Inhaltsverzeichnis

7

6 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596.1 Interaktives Rebasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

6.1.1 Branches pseudo-sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606.1.2 Den letzten Commit verändern. . . . . . . . . . . . . . . . . . . . . . . . 1616.1.3 Mehrere Commits verändern . . . . . . . . . . . . . . . . . . . . . . . . . 1636.1.4 Reihenfolge der Commits anpassen . . . . . . . . . . . . . . . . . . . . 1656.1.5 Commits ergänzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666.1.6 Commits squashen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676.1.7 Commits autosquashen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696.1.8 Commits droppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706.1.9 Commit aufteilen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

6.2 Workflow mit einem Branch und Repository für eine Person. . . . . . 1716.3 Workflow mit mehreren Personen, einem Repository und

einem Branch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736.4 Git Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

6.4.1 Feature-Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766.4.2 Release-Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786.4.3 Release taggen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796.4.4 Hotfix-Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1806.4.5 Zusammenfassung zu Git Flow . . . . . . . . . . . . . . . . . . . . . . . 181

6.5 Git Flow mit mehr als einem develop-Branch. . . . . . . . . . . . . . . . . . . 1826.6 GitHub-Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836.7 Git Flow mit mehreren Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . 1846.8 Git-Flow-Alternative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1856.9 Auswahl des Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

7 Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1877.1 Client-seitige Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

7.1.1 Commit-Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1887.1.2 E-Mail-Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1907.1.3 Weitere Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

7.2 Server-seitige Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917.2.1 pre-receive-Hook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1927.2.2 update-Hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1927.2.3 post-receive-Hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1927.2.4 Beispiel-Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

7.3 Git-Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Inhaltsverzeichnis

8

8 Umstieg von Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1978.1 Zentrale vs. verteilte Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1978.2 Checkout vs. Clone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1988.3 svn commit vs. git commit & git push . . . . . . . . . . . . . . . . . . . . . . . . . 1988.4 svn add vs. git add . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1988.5 Binärdateien im Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1998.6 SVN- in Git-Repository konvertieren . . . . . . . . . . . . . . . . . . . . . . . . . . 199

8.6.1 git-svn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1998.6.2 Nach der Umwandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2028.6.3 Committen mit git-svn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

8.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

9 Tipps und Tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2059.1 Aliasse setzen und nutzen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2059.2 Mehr aus dem Log holen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

9.2.1 Begrenzte Ausgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2069.2.2 Schönere Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

9.3 Ausgeführte Aktionen im Repository mit git reflog . . . . . . . . . . . . . . 2099.4 Garbage Collection mit git gc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2129.5 Finde den Schuldigen mit git blame . . . . . . . . . . . . . . . . . . . . . . . . . . 2129.6 Wortweises diff mit word-diff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2139.7 Datei-Inhalte suchen mit git grep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2149.8 Änderungen häppchenweise stagen und committen . . . . . . . . . . . . . 2159.9 Auf Fehlersuche mit git bisect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2179.10 Arbeiten mit Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

9.10.1 Patches erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2199.10.2 Patches anwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

9.11 Repositories in Repositories mit git submodules . . . . . . . . . . . . . . . . 2239.12 Komplette Historie neu schreiben mit git filter-branch . . . . . . . . . . . 2269.13 Notizen erstellen mit git notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2289.14 Tippfehler in Git-Befehlen automatisch korrigieren . . . . . . . . . . . . . . 2299.15 Liquid Prompt für Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

9.15.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2309.15.2 Im Einsatz mit Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

9.16 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

10 Grafische Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23510.1 Git GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23510.2 Gitk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Inhaltsverzeichnis

9

10.3 SourceTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24010.4 GitHub Desktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24310.5 Gitg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24410.6 Tig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24510.7 TortoiseGit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24710.8 GitKraken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24910.9 Weiteres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

A Befehlsreferenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251A.1 Repository und Arbeitsverzeichnis anlegen . . . . . . . . . . . . . . . . . . . . 251A.2 Erweiterung und Bearbeitung der Historie . . . . . . . . . . . . . . . . . . . . . 252

A.2.1 Arbeiten im Staging-Bereich . . . . . . . . . . . . . . . . . . . . . . . . . . 252A.2.2 Arbeiten mit Commits und Branches. . . . . . . . . . . . . . . . . . . 253

A.3 Statusausgaben und Fehlersuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256A.4 Verteilte Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257A.5 Hilfsbefehle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258A.6 Sonstige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

11

Danksagung

An einem Buch arbeitet selten eine Person vollständig allein. An dieser Stellemöchte ich daher Thomas Schmidt und Sarah Blume danken, die sich die Zeitgenommen haben, mir gutes Feedback zu meinem Manuskript zu geben, das indas Buch eingeflossen ist. Weiterhin gilt mein Dank auch Dirk Deimeke für dieinitiale Idee und Motivation, dieses Buch zu schreiben, sowie Dr. Veit Jahns vonder otris software AG aus Dortmund, wo ich im Wesentlichen mein Wissen vonGit erwerben, anwenden und neue Ideen einbringen konnte. Zum Schluss gehtmein Dank noch an das Team von ubuntuusers.de und freiesMagazin.de, ohne dieich wohl nie ein Buch geschrieben hätte.

13

Einleitung

»If that doesn't fix it, git.txt contains the phone number of a friend of minewho understands git. Just wait through a few minutes of 'It's really pretty sim-ple, just think of branches as...' and eventually you'll learn the commands thatwill fix everything.«

(»Und wenn das auch nicht hilft, dann enthält git.txt die Telefonnummereines Freundes, der sich mit Git auskennt. Warte einfach ein paar Minutenvon »Es ist wirklich gar nicht so schwer, stell dir vor, die Branches wären ...« abund irgendwann lernst du die Befehle, die jedes Problem fixen.«)

»xkcd: Git«, Copyright Randall Munroe (https://xkcd.com/1597/) istlizenziert unter der Creative Commons Lizenz CC BY-NC 2.5 (https://creativecommons.org/licenses/by-nc/2.5/)

Das ist Git. Es bietet einen Überblick über die kollaborative Arbeit in Projekten durch die Nutzung eines wunderschönen Graphen-Theorie-Modells.

Cool. Aber wie nutzt man es?

Keine Ahnung. Merk 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.

Einleitung

14

Versionskontrolle ist ein wichtiges Thema für Software-Entwickler. Jeder, der ohnejegliche Versionskontrollprogramme arbeitet, ist vermutlich schon einmal an denPunkt gestoßen, wo man sich ältere Stände ansehen wollte, sich gefragt hat,warum und wann man eine Funktion eingeführt hat, oder auch mal auf einen älte-ren Stand zurückspringen wollte, wenn man etwas kaputt gemacht hat. Genau andieser Stelle kommen Versionsverwaltungsprogramme ins Spiel. Git ist eines die-ser Programme, das nicht nur die bereits genannten Probleme lösen, sondern dasman auch gut in die Entwicklungsprozesse einfügen kann, um sowohl kollabora-tiv als auch alleine an einem Projekt zu arbeiten. Dabei ist es gleichgültig, ob manProgrammierer, System-Administrator oder gar Autor ist.

Randall Munroe beleuchtet in seinem Webcomic xkcd viele verschiedene Themen.Das hier abgedruckte xkcd-Comic zum Thema Git wurde während meiner Arbeitan diesem Buch veröffentlicht. Viele meiner Freunde und Bekannten aus demOpen-Source-Umfeld posteten das Comic in den verschiedenen sozialen Netzwer-ken und es machte eins deutlich: Viele Leute nutzen Git zwar, wissen aber nurgrob, was dort passiert. Wenn etwas nicht wie geplant funktioniert oder man zueinem fehlerhaften Zustand im Arbeitsprojekt kommt, dann weiß man erst malnicht weiter und fragt seinen persönlichen Git-Experten.

Das Ziel dieses Buches ist nicht nur, dass Sie die gängigen Befehle erlernen, diebeim Arbeiten mit Git gebraucht werden. Ich lege auch großen Wert auf die Ein-bindung und Anpassung des Entwicklungsprozesses. Darüber hinaus sollten SieGit als Ganzes verstehen und nicht nur die Grundlagen, damit Sie mit einem Pro-gramm arbeiten, das Sie verstehen und bei dem bei Konflikten keine Hürden vor-handen sind.

Aufbau des Buches

Dieses Buch besteht aus insgesamt zehn Kapiteln, davon gehören die ersten vierKapitel zu den Grundlagen und die übrigen sechs zu den fortgeschrittenen The-men.

Das erste Kapitel führt in das Thema der Versionsverwaltung mit Git ein, um denEinsatzzweck und die Vorteile von Git zu verdeutlichen. Das zweite Kapitel behan-delt die grundlegenden Git-Kommandos. Dies beinhaltet die Basis-Befehle, die fürdas Arbeiten mit Git notwendig sind. Im anschließenden dritten Kapitel geht esum die Nutzung von Branches, eines der elementaren Features von Git. So lernenSie, mit Branches parallele Entwicklungslinien zu erstellen, zwischen diesen ver-schiedenen Branches hin- und herzuwechseln und sie wieder zusammenzufüh-ren. Der Grundlagenteil endet mit dem vierten Kapitel, bei dem es um den Einsatzvon verteilten Repositories geht, die es ermöglichen, mit Repositories zu arbeiten,die auf entfernten Servern, wie etwa GitHub, liegen.

Konvention

15

Bei den fortgeschrittenen Themen liegt der Fokus besonders auf dem Einsatz vonGit in Software-Entwicklungsteams. Wichtig ist es dabei, über eine gute Möglich-keit zu verfügen, Git-Repositories hosten zu können, damit man kollaborativ ineinem Team an Projekten arbeiten kann. Während die wohl gängigste, bekann-teste und einfachste Hosting-Möglichkeit GitHub ist, gibt es auch einige Open-Source-Alternativen, wie zum Beispiel GitLab, die sich ebenfalls gut für den Ein-satz in Firmen oder anderen Projektgruppen eignen. Das ist das Thema im fünf-ten Kapitel, in dem auch der Workflow bei GitHub und GitLab thematisiert wird.Im anschließenden sechsten Kapitel geht es um die verschiedenen existierendenWorkflows. Um die Features von Git sinnvoll einzusetzen, sollten Sie einen Work-flow nutzen, der sowohl praktikabel ist als auch nicht zu viel Overhead im Projektbedeutet. Die Art und Weise, mit Git zu arbeiten, unterscheidet sich vor allem beider Anzahl der Personen, Branches und Repositories. Im sechsten Kapitel geht esim Anschluss darum, Git-Hooks zu verwenden, um mehr aus dem Projekt heraus-zuholen oder simple Fehler automatisiert zu überprüfen und somit zu vermeiden.So lernen Sie, was Hooks sind, wie sie programmiert werden und damit zu auto-matisieren. Generell ist dieses Kapitel für den Git-Nutzer kein alltägliches Thema.Hooks werden im Alltag eher unregelmäßig programmiert.

Die abschließenden drei Kapitel befassen sich zunächst mit dem Umstieg vonSubversion nach Git, wobei sowohl die Übernahme des Quellcodes inklusive derHistorie als auch die Anpassung des Workflows thematisiert wird. Das vorletzteKapitel ist eine Sammlung vieler verschiedener nützlicher Tipps, die zwar nichtzwangsläufig täglich gebraucht werden, aber trotzdem sehr nützlich sein können.

Zum Abschluss folgt dann noch ein Kapitel mit einem Überblick über die grafi-schen Git-Programme unter den verschiedenen Betriebssystemen Windows, MacOS X und Linux.

Um den Einsatz von Git und die einzelnen Funktionen sinnvoll nachvollziehen zukönnen, werden alle Git-Kommandos anhand eines realen Beispiels erläutert.Über die Kapitel des Buches hinweg entsteht eine kleine statische Webseite, an derdie Funktionen verdeutlicht werden. Denn was bringt es, die Kommandos von Gitohne den Bezug zu realen Projekten und dessen Einsatzzwecke zu kennen? Einekleine Webseite hat insbesondere den Vorteil, dass Sie nicht nur Unterschiede imQuellcode nachvollziehen, sondern auch sehr einfach die optischen Unterschiedeauf einer Webseite erkennen können.

Konvention

In diesem Buch finden Sie zahlreiche Terminal-Ausgaben abgedruckt. Diese sindgrößtenteils vollständig, einige mussten aus Platz- und Relevanz-Gründen jedochgekürzt werden. Eingaben in der Kommandozeile fangen immer mit dem »$« an.

Einleitung

16

Dahinter folgt dann der eigentliche Befehl. Das Dollarzeichen ist der Prompt, derin der Shell dargestellt wird, und es muss daher nicht eingetippt werden. Zeilen,die kein solches Zeichen besitzen, sind Ausgaben der Befehle. Das sieht dann etwaso aus:

Zeilen, die nicht relevant sind oder verkürzt wurden, sind als »[...]« dargestellt.

An einigen Stellen kommt es vor, dass die Befehle so lang sind, dass sie sich nichtohne Umbruch abdrucken lassen. Diese Stellen werden mit einem Umbruchzei-chen visualisiert, das nicht mit eingetippt werden muss.

Hinweise und Tipps

Die einzelnen Kapitel bauen zwar aufeinander auf, doch ist es nicht immer mög-lich, alle Themen an Ort und Stelle ausführlich zu behandeln. Zudem werdenwohl eher wenige Leser das Buch von vorne bis hinten durcharbeiten. Das Buchbeinhaltet daher einige Hinweise und Tipps. Teilweise sind es Hinweise aufnähere Details in anderen Teilen des Buches, teilweise Tipps und Warnungen fürdie Nutzung von Git. Dies sind häufig nützliche Inhalte, die sich auf das geradebehandelte Thema beziehen, hin und wieder aber auch Querverweise zu näherenErläuterungen in anderen Kapiteln.

Feedback

Als Autor habe ich sehr wohl den Anspruch, dass Sie als Leser das, was in die-sem Buch behandelt wird, sowohl richtig verstehen als auch anwenden können.Ich bin daher offen für Feedback und Verbesserungsvorschläge – entweder perMail an mail@svij.org oder Kurzes gerne auch via Twitter an @svijee(https://twitter.com/svijee). Bin sehr an Feedback interessiert!

$ git log

commit 9534d7866972d07c97ad284ba38fe84893376e20

[...]

17

Kapitel 1

Einführung

1.1 Versionsverwaltung

Zu Beginn stellt sich die Frage, was denn genau ein Versionsverwaltungspro-gramm ist, worin es sich auszeichnet und warum es gebraucht wird. Die prinzi-pielle Bedeutung leitet sich schon aus dem Wort selbst ab: Es handelt sich um dieVerwaltung von Versionen. Konkret bedeutet es, dass Sie von Dateien Versionenerzeugen können, die dann sinnvoll verwaltet werden können.

Das Wort »Version« klingt zunächst erst mal nach größeren Änderungen, dochauch kleine Änderungen erzeugen eine neue Version einer Datei. Generell gibtes ein unterschiedliches Verständnis für den Begriff »Version«. Wenn bei Gitvon Versionen gesprochen wird, ist damit so gut wie immer die Version einereinzelnen Datei oder einer Sammlung von Dateien gemeint. Im Sinne der Soft-ware-Entwicklung werden neue Versionen von Programmen veröffentlicht, alsozum Beispiel die Git-Version 2.7.

Aber wofür brauchen Sie nun ein Versionsverwaltungsprogramm wie Git? Vielekennen vermutlich folgendes Problem: Man geht einer Tätigkeit nach – sei es dasSchreiben an einem Text, das Bearbeiten eines Bildes oder eines Videos – und deraktuelle Stand soll immer mal wieder zwischengespeichert werden, damit zumeinen eine Sicherung der Datei vorhanden ist und zum anderen, damit wieder aufeinen älteren Stand zurückgesprungen werden kann, falls doch einige Schritterückgängig gemacht werden sollen. Die Taktik, um solche Versionen zu erzeugen,ist unterschiedlich – die einen fügen Zahlen mit Versionsnummern am Ende desDateinamens an, die anderen erzeugen wiederum Ordner mit dem aktuellenDatum, worin die Dateien liegen. So passiert es häufiger mal, dass neben Bache-lorarbeit_v1.odt und Bachelorarbeit_v2.odt noch ein Bachelorarbeit_v3_final.odt und Bachlorarbeit_v3_final_new.odt liegt. Beide genanntenMöglichkeiten funktionieren zwar prinzipiell, sind allerdings weder praktikabelnoch wirklich sicher und vor allem fehleranfällig, besonders dann, wenn Sie denDateien keine eindeutigen Namen gegeben haben. Dies trifft insbesondere dannzu, wenn zu viele Versionen einer einzigen Datei rumliegen oder gleich mehrereDateien versioniert werden müssen.

Genau bei diesem Problem kommen Versionsverwaltungsprogramme zum Ein-satz. Mit diesen werden neben den reinen Veränderungen noch weitere Informa-tionen zu einer Version gespeichert. Darunter fallen in der Regel der Autorenname,

Kapitel 1Einführung

18

die Uhrzeit der Änderung und eine Änderungsnotiz. Diese werden bei jeder neuenVersion gespeichert. Durch die gesammelten Daten können Sie so schnell und ein-fach eine Änderungshistorie ansehen und verwalten. Falls zwischendurch Fehler inden versionierten Dateien eingeflossen sind, können Sie leicht untersuchen, wannund durch welche Person die Fehler eingeführt wurden, und diese wieder rückgän-gig machen. Versionsverwaltungsprogramme lassen sich demnach nicht nur voneinzelnen Personen nutzen, sondern ermöglichen das Arbeiten im Team mit mehrals einer Person.

Mit den Versionsverwaltungsprogrammen lassen sich alle möglichen Dateitypenverwalten. Allerdings ist dabei zu beachten, dass eine Versionierung nicht fürjeden Dateityp praktikabel ist. Besonders hilfreich sind solche Anwendungen vorallem für Arbeiten mit reinen Text-Dateien. Darunter fallen insbesondere Quell-code von Programmen, Konfigurationsdateien oder auch Texte und Bücher. DerVorteil bei reinen Text-Dateien ist, dass Sie die Unterschiede bei Änderungen fürjede Zeile nachvollzogen können – das ist bei binären Dateien nicht möglich.Auch für Grafiker kann der Einsatz eines Versionsverwaltungsprogramms sinn-voll sein, denn mit zusätzlichen Tools können auch die Veränderungen zwischenzwei Versionen von Bildern dargestellt werden.

Insgesamt gibt es drei verschiedene Konzepte zur Versionsverwaltung: die lokale,die zentrale und die verteilte Versionsverwaltung.

1.1.1 Lokale Versionsverwaltung

Abb. 1.1: Lokale Versionsverwaltung arbeitet Datei-basiert und lediglich lokal.

Die lokale Versionsverwaltung findet sich eher seltener in produktiven Umgebun-gen, da sie lediglich lokal arbeitet und häufig nur einzelne Dateien versioniert. Die

1.1Versionsverwaltung

19

zuvor erwähnte manuelle Erzeugung von Versionen von Dateien wäre zum Beispieleine lokale Versionsverwaltung mit einer einzelnen Datei. Sie ist zwar einfach zunutzen, doch auch fehleranfällig und wenig flexibel. Echte Versionsverwaltungs-software, die nur lokal arbeitet, gibt es allerdings auch, z.B. »SCSS« und »RCS«.Der größte Nachteil lokaler Versionsverwaltung ist, dass im Normalfall nur einePerson mit den Dateien arbeiten kann, da diese nur lokal auf dem einen Gerät ver-fügbar sind. Ein weiterer Nachteil ist, dass keine Datensicherheit besteht, da dieDateien nicht automatisch auf einem anderen Gerät gesichert werden. Der Anwen-der ist somit allein verantwortlich für ein Backup der Dateien inklusive der Ver-sionshistorie.

1.1.2 Zentrale Versionsverwaltung

Abb. 1.2: Zentrale Versionsverwaltung arbeitet mit Arbeitskopien auf Clients.

Zentrale Versionsverwaltungen befinden sich heute noch häufig im Einsatz.Bekannte Vertreter dieser Art sind Subversion und CVS. Das Hauptmerkmal zen-traler Versionsverwaltungen ist, dass das Repository lediglich auf einem zentralenServer liegt. Das Wort »Repository« ist Englisch und steht für »Lager«, »Depot«oder auch »Quelle«. Ein Repository ist somit ein Lager, in dem die versioniertenDateien liegen. Autorisierte Nutzer verfügen über eine lokale Arbeitskopie einerVersion, auf der sie ihre Arbeiten erledigen.

Die Logik der Versionsverwaltung liegt größtenteils auf dem zentralen Server.Beim Wechsel von Revisionen oder beim Vergleichen von Änderungen wird stetsmit dem Server kommuniziert. Wenn der Server also offline ist, kann der Nutzerzwar mit der Arbeitskopie ein wenig weiterarbeiten, ältere Versionen einzusehenoder das Ansehen von anderen Entwicklungslinien ist hingegen nicht möglich, daes sich um eine Arbeitskopie einer Version und keine Arbeitskopie des vollständi-gen Repositorys handelt.

Kapitel 1Einführung

20

1.1.3 Verteilte Versionsverwaltung

Abb. 1.3: Verteilte Versionsverwaltung arbeitet mit Repositories auf Clients und Servern.

Git gehört zu den verteilt arbeitenden Versionsverwaltungsprogrammen. NebenGit gibt es auch andere verteilte Versionskontrollprogramme, wie Bazaar oderMercurial. Im Gegensatz zur zentralen Versionsverwaltung besitzt jeder Nutzerdes Repositorys nicht nur eine Arbeitskopie, sondern das komplette Repository.Wenn also zwischen verschiedenen Revisionen gewechselt wird oder der Anwen-der sich die Historie von einzelnen Dateien anschauen möchte, dann geschiehtdas Ganze auf dem lokalen Rechner. Zuvor muss nur das Repository »geklont«werden. Alle Funktionen stehen dann auch offline zur Verfügung. Ein wesentli-cher Vorteil davon ist, dass nicht nur unnötiger Netzwerk-Verkehr vermiedenwird, sondern auch die Geschwindigkeit deutlich höher ist, was durch die feh-lende Netzwerk-Latenz bedingt ist.

Zusätzlich besitzen verteilte Versionsverwaltungssysteme eine höhere Datenaus-fallsicherheit, da die Kopien der Daten des Repositorys in der Regel auf verschiede-nen Rechnern liegen. Bei einem Ausfall des Git-Servers ist es daher möglich,weiterzuarbeiten. Nichtsdestotrotz sollten Sie von wichtigen Daten natürlichimmer Backups anfertigen, ganz egal ob es sich um lokale, zentrale oder verteilteVersionsverwaltung handelt.

Um den Unterschied zwischen zentralen und verteilten Versionsverwaltungspro-grammen klarer zu machen, kann folgendes Beispiel helfen. Stellen Sie sich vor,dass das Repository ein dicker Aktenordner ist. Darin enthalten sind alle aktuellenDateien, ältere Versionen der Dateien sowie die Änderungshistorie mitsamt denKommentaren zu den Änderungen. Sie müssen mit diesen Dateien arbeiten.Wenn es sich um ein zentrales System handelt, dann befindet sich der Aktenord-ner an einer zentral zugänglichen Stelle, die hier nun Archiv genannt wird. Für Sieheißt es, dass Sie zum Archiv und zu dem Ordner gehen müssen. Dort wird danneine Arbeitskopie der benötigten Dateien erzeugt und anschließend laufen Siewieder zurück zum Arbeitsplatz. Wenn Sie die Änderungshistorie von einer oder

1.1Versionsverwaltung

21

mehreren Dateien ansehen möchten, müssen Sie immer wieder zum Archiv lau-fen und den Aktenordner durchblättern, um sich diese anzusehen. Da es sowohlZeit als auch Energie kostet, immer zum zentralen Aktenordner zu laufen, bietetes sich an, eine Kopie des ganzen Ordners zu erstellen und mit an Ihren Arbeits-platz zu nehmen.

Abb. 1.4: Die Versionshistorie liegt sowohl lokal als auch auf dem Server.

Genau das ist dann eine verteilte Versionsverwaltung, da nun zwei vollständigeKopien des Aktenordners existieren – einmal an zentraler Stelle im Archiv undeinmal am eigenen Arbeitsplatz. Der Vorteil ist, dass nach der ersten Kopie nurnoch die Veränderungen hin- und hergetragen werden müssen. Alles andere kannbequem vom Arbeitsplatz aus gemacht werden, ohne ständig aufzustehen undherumlaufen zu müssen. Konkret bedeutet das, dass Sie an Ihrem Arbeitsplatz sit-zen und Ihre Aufgaben erledigen. Sobald die Arbeit abgeschlossen ist, tragen Sienur die neuen Dateien zum Archiv, wo Sie eine Kopie anfertigen und diese im zen-tralen Aktenordner abheften. Großer Vorteil ist, dass Sie auch weiterhin arbeitenkönnen, wenn der Weg zum Aktenordner unzugänglich ist, etwa genau dann,wenn Sie unterwegs sind.

Zusammenfassung

� Die lokale Versionsverwaltung funktioniert lediglich auf einem einzelnenRechner.

� Bei der zentralen Versionsverwaltung liegt das »Gehirn« auf einem zentralenServer, von dem sich alle Mitarbeiter eine Arbeitskopie ziehen können.

� Bei der verteilten Versionsverwaltung liegt das vollständige Repository so-wohl auf mindestens einem Server sowie auf allen Clients, wo mit Klonengearbeitet wird.

Kapitel 1Einführung

22

1.2 Geschichtliches

Seinen Ursprung hatte Git bei der Entwicklung des Linux-Kernels. Letztererwurde lange Zeit mit BitKeeper verwaltet, das damals ein proprietäres Programmwar. Nachdem die Hersteller von BitKeeper die Lizenz geändert hatten, konntendie Linux-Kernel-Entwickler um Linus Torvalds BitKeeper nicht mehr kostenfreiverwenden, weswegen Linus Torvalds mit der Entwicklung von Git begann. Erstim 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ünge-ren Versionsverwaltungssystemen und das, obwohl es mittlerweile zehn Jahre altist. Linus Torvalds fand es wichtig, dass das zukünftig eingesetzte Programm zurEntwicklung des Linux-Kernels drei spezielle Eigenschaften besitzt. Das sind zumErsten Arbeitsabläufe, die an BitKeeper angelehnt sind, zum Zweiten die Sicher-heit gegen böswillige und unbeabsichtigte Verfälschung des Repositorys sowiezum Dritten eine hohe Effizienz. Das Projekt »Monotone« wäre nahezu perfektfür diese Aufgabe gewesen. Das einzige Problem war nur, dass es nicht sonderlicheffizient arbeitete. Letztendlich entschied sich Linus Torvalds für die Entwicklungeines komplett neuen Programms, was er dann Git nannte.

Interessant ist auch die Namensgebung von Git. Das Wort »Git« ist das englischeWort für »Blödmann«. Linus Torvalds selbst sagte spaßeshalber: »I’m an egoisticalbastard, and I name all my projects after myself. First ›Linux‹, now ›Git‹.«(Deutsch: »Ich bin ein egoistischer Bastard, und ich benenne alle meine Projektenach mir selbst. Erst ›Linux‹ und nun ›Git‹.«). Natürlich gab es auch echteGründe, das Projekt »Git« zu taufen. Zum einen enthält das Wort lediglich dreiBuchstaben, was das regelmäßige Tippen auf der Tastatur erleichtert, zum ande-ren gab es kein UNIX-Kommando, mit dem es kollidieren würde.

23

Kapitel 2

Die Grundlagen

Dieses Kapitel beinhaltet die grundlegenden Funktionen und Kommandos vonGit. So gut wie alle in diesem Kapitel behandelten Befehle dürften beim täglichenArbeiten mit Git zum Einsatz kommen. Damit Sie den Sinn und Zweck einzelnerBefehle und Funktionen von Git sowohl nutzen als auch nachvollziehen können,arbeitet dieses Kapitel hauptsächlich an einem Beispielprojekt, das die Nutzungund Arbeitsweise von Git verdeutlicht.

Das Beispiel-Projekt ist eine kleine Webseite, die nach und nach aufgebaut wird.HTML-Kenntnisse sind prinzipiell nicht notwendig, können aber natürlich auchnicht schaden. Damit es nicht ganz so trocken und langweilig ist, empfehle ichIhnen, die Beispiele auf dem eigenen Rechner nachzumachen und an der ein oderanderen Stelle auch etwas herumzuexperimentieren, denn nur durch Praxis wirdIhnen das Arbeiten mit Git klar und Sie haben hinterher in echten Projekten keinegroßen Probleme.

Als Beispiel wird eine kleine persönliche Webseite mit dem HTML5-Framework»Bootstrap« erstellt. Auf die genaue Funktionsweise des Frameworks gehe ichnicht 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 derArbeit mit Git in der Kommandozeile liegt. Einschübe mit grafischen Git-Pro-grammen gibt es dennoch. Grafischen Git-Programmen ist mit Kapitel 10, »Grafi-sche Clients«, ein vollständiges Kapitel gewidmet.

2.1 Installation

Bevor Sie losgelegen, muss Git installiert werden. Git gibt es für die Betriebssys-teme Windows, Mac OS X und Linux. Die gängigen Linux-Distributionen stellenGit unter dem Paketnamen »git« in der Paketverwaltung zur Verfügung. Nutzervon Windows und Mac OS X können sich Git von der Projektwebseite https://git-scm.com/downloads herunterladen.

Während der Arbeit an diesem Buch sind die Git-Versionen 2.5 bis 2.9 erschienen,wesentliche Unterschiede in diesen Versionen gab es nicht, sodass das Buch zueinem sehr großen Teil auf der Version 2.5 basiert. Seit der Version 2.5 hat Git

Kapitel 2Die Grundlagen

24

unter Windows keinen Preview-Status mehr, sondern ist als vollwertige stabileVersion verfügbar. In den Paketverwaltungen der diversen Linux-Distributionenliegen verschiedene Versionen. Es gibt einige kleinere Unterschiede in der Benut-zung zwischen den Git-Versionen vor und nach der Version 2.0. An den Stellen imBuch, an denen es zu Abweichungen zwischen verschiedenen Git-Versionenkommt, habe ich zusätzlich hervorgehoben, was Sie beachten müssen und wo dieUnterschiede liegen.

Die Installation unter Windows ist größtenteils selbsterklärend. Sie sollten aller-dings die Unterschiede bei der Nutzung der Shell beachten. Die Shell ist das Fens-ter, in dem die Kommandozeilenbefehle eingetippt werden. Git lässt sich sowohlin der Windows-Cmd nutzen als auch in der »Git-Bash«.

Abb. 2.1: Wenn Git von der Windows-Cmd genutzt werden soll, muss die Option aktiviert werden.

Wenn Git zusätzlich in der Windows-Cmd genutzt werden soll, muss es in derPATH-Variablen eingetragen werden. Dies ist nicht der Standard, wenn Git instal-liert wird, sondern Sie müssen es explizit auswählen, wie am obigen Screenshotzu erkennen ist.

Eine weitere Konfiguration, die während der Installation abgefragt wird, ist dieEinstellung bezüglich des Verhaltens des Zeilenendes. Der Standard ist, dass beimAuschecken von Dateien das Zeilenende von LF zu CRLF umgewandelt wird undbeim Committen in das Repository wieder in LF. Sofern man nicht weiß, was pas-siert, sollte man die anderen Optionen ausdrücklich nicht auswählen.

2.2Das erste Repository

25

Abb. 2.2: Konfiguration des Verhaltens bezüglich des Zeilenendes

Bei der Nutzung von Git präferiere ich die Git-Bash, da sie im Defaultzustandeinige zusätzliche Funktionen bietet, wie die Anzeige des Namens des aktuellenBranches. Außerdem können die gängigen Unix-Kommandos verwendet werden.Alle Befehle in diesem Buch lassen sich problemlos in einer Shell unter Mac OS Xund Linux bzw. der Git-Bash unter Windows ausführen. Die Windows-Cmd kannzwar auch verwendet werden, allerdings nenne ich Windows-Cmd-Kommandosnicht noch einmal explizit. Dies ist unter anderem dann relevant, wenn etwa Ord-ner angelegt oder Dateien verschoben werden.

Abb. 2.3: Git-Bash unter Windows

2.2 Das erste Repository

Da Git ein verteiltes Versionsverwaltungsprogramm ist, lassen sich alle Operationenan einem Repository vollständig lokal ausführen. Alle Git-Funktionen, die in diesem

Kapitel 2Die Grundlagen

26

Kapitel erläutert werden, sind ohne Ausnahme lokale Befehle auf dem eigenen Rech-ner. Verbindungen zu externen Git-Servern werden also nicht aufgenommen.

Bevor die ersten Dateien in ein Repository geschoben werden können, muss eslokal angelegt werden. Da Git ein Kommandozeilenprogramm ist, müssen Siejetzt unter einem Linux- oder Mac-Betriebssystem das Terminal öffnen. Windows-Nutzer rufen an dieser Stelle die Git-Bash auf.

Im Defaultzustand landet man dann im Home-Verzeichnis des Nutzerkontos. Diesist etwa /home/svij unter Linux, C:\Users\svij unter Windows oder /Users/svij unter Mac OS X. In diesem oder in einem anderen beliebigen Verzeichnismüssen Sie nun einen Unterordner namens meineWebseite anlegen, in dem dasRepository und dessen Daten liegen sollen. Anschließend wechseln Sie mit demcd-Befehl in das Verzeichnis.

In diesem Verzeichnis soll nun das Git-Repository angelegt werden. Dazu reichtein einfaches Ausführen des folgenden Befehls:

Die Ausgabe des Befehls verrät schon, was passiert ist. Git hat innerhalb des Pro-jekt-Ordners ein .git-Verzeichnis angelegt, in dem das leere Git-Repository liegt.Es liegen zwar Dateien und Ordner im .git-Verzeichnis, doch ist das Repositoryprinzipiell leer, da noch keine Daten und keine Revisionen hinterlegt sind. DasVerzeichnis ist auf allen Betriebssystemen versteckt. Das Gedächtnis des Git-Repo-sitorys liegt vollständig im .git-Unterverzeichnis. Falls man das Verzeichnislöscht, sind auch alle gespeicherten Informationen des Repositorys gelöscht. Zumjetzigen Zeitpunkt wäre das natürlich nicht so tragisch, da es noch leer ist.

An dieser Stelle lohnt sich schon ein kleiner Blick in dieses Verzeichnis:

$ mkdir meineWebseite

$ cd meineWebseite

$ git init

Initialisiere leeres Git-Repository in ~/meineWebseite/.git/

$ ls -l .git

insgesamt 32

drwxr-xr-x 2 sujee sujee 4096 16. Sep 10:44 branches

-rw-r--r-- 1 sujee sujee 92 16. Sep 10:44 config

-rw-r--r-- 1 sujee sujee 73 16. Sep 10:44 description

-rw-r--r-- 1 sujee sujee 23 16. Sep 10:44 HEAD

drwxr-xr-x 2 sujee sujee 4096 16. Sep 10:44 hooks

drwxr-xr-x 2 sujee sujee 4096 16. Sep 10:44 info

2.3Git-Konfiguration

27

Wie man sieht, liegen in dem .git-Verzeichnis einige Ordner und Dateien. Wasgenau darin passiert, ist an dieser Stelle zunächst irrelevant. Händisch muss indiesem Verzeichnis in der Regel zunächst nichts unternommen werden, außerwenn Sie Hooks – für das Ausführen von Skripten bei diversen Aktionen – oderdie Konfiguration anpassen möchten. Allerdings sollten Sie die Dateien nur anfas-sen, wenn Ihnen bekannt ist, zu welchen Auswirkungen es führt, denn das Repo-sitory kann sonst kaputt gemacht werden!

2.3 Git-Konfiguration

Da Sie bereits ein leeres Repository angelegt haben, können Sie nun ein Commithinzufügen. Was genau ein Commit ist und wie es getätigt werden kann, wirdspäter genau erläutert. Denn zunächst müssen Sie noch die Git-Installation kon-figurieren.

Vorerst werden allerdings nur zwei Dinge konfiguriert: der eigene Entwickler-name und die dazugehörige E-Mail-Adresse.

Mit den folgenden Befehlen können Sie den eigenen Namen und die eigeneE-Mail-Adresse setzen:

Mit diesen beiden Befehlen wird die Datei .gitconfig im Home-Verzeichnisangelegt. Der Inhalt der Datei in ~/.gitconfig sieht anschließend so aus:

Mit dem Befehl git config -l lässt sich die Konfiguration ebenfalls über dieKommandozeile ansehen.

Beachten Sie, dass bei den oben genannten Befehlen die Git-Identität global für dasBenutzerkonto des Betriebssystems gesetzt wird. Wenn Sie für einzelne Git-Reposi-tories spezifische Einstellungen setzen möchten, reicht es, den Aufruf-Parameter--global wegzulassen. Die Konfiguration wird dann in die Datei .git/config imProjektordner gespeichert. Dies ist häufig dann sinnvoll, wenn Sie verschiedene

drwxr-xr-x 4 sujee sujee 4096 16. Sep 10:44 objects

drwxr-xr-x 4 sujee sujee 4096 16. Sep 10:44 refs

$ git config --global user.name "Sujeevan Vijayakumaran"

$ git config --global user.email mail@svij.org

$ cat ~/.gitconfig

[user]

name = Sujeevan Vijayakumaran

email = mail@svij.org

Kapitel 2Die Grundlagen

28

E-Mail-Adressen für verschiedene Projekte nutzen. Das trifft beispielsweise dannzu, wenn Sie für die Erwerbsarbeit eine E-Mail-Adresse verwenden und für privateRepositories eine andere. Die angegebenen Informationen zu einem Entwicklersind für alle Personen einsehbar, die mindestens Lese-Rechte im Repository besit-zen, sofern der Entwickler mindestens einen Commit getätigt hat.

2.4 Der erste Commit

An dieser Stelle startet das »echte« Arbeiten mit dem Git-Repository. Wie bereitsvorher 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 git status:

Dieser Befehl gibt immer sinnvolle und praktische Informationen aus, die für dasArbeitsverzeichnis-Repository zu der entsprechenden Zeit hilfreich sind. Zum jet-zigen Zeitpunkt teilt es mit, dass man sich auf dem Branch master befindet, essich um den »Initialen Commit« handelt 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 Commitzu tätigen. Da in diesem Beispielprojekt das HTML5-Framework Bootstrap ver-wendet wird, müssen Sie dieses zunächst herunterladen und entpacken. Dieskann entweder händisch geschehen oder Sie führen folgende Befehle aus. Fallscurl nicht installiert ist, was bei einigen Linux-Distributionen der Fall seinkann, können Sie es nachinstallieren, das Programm wget nutzen oder die Dateiüber den angegebenen Link händisch über den Browser herunterladen und ent-packen.

$ git status

Auf Branch master

Initialer Commit

nichts zu committen (Erstellen/Kopieren Sie Dateien und benutzen Sie "git add" zum Versionieren)

$ curl -o bootstrap.zip -L https://github.com/twbs/bootstrap/releases/download/v3.3.5/bootstrap-3.3.5-dist.zip

$ unzip bootstrap.zip

$ mv bootstrap-3.3.5-dist/* .

$ rmdir bootstrap-3.3.5-dist

$ rm bootstrap.zip