Startseite

Vorwort
1. An wen richtet sich dieses Buch?
2. Wie ist das Buch zu lesen?
3. Konventionen
4. Installation und „das Git-Repository“
5. Dokumentation und Hilfe
6. Downloads und Kontakt
7. Danksagungen
8. Vorwort zur 2. Auflage
9. Vorwort zur CreativeCommons-Ausgabe
1. Einführung und erste Schritte
1.1. Grundbegriffe
1.2. Erste Schritte mit Git
1.3. Git konfigurieren
2. Grundlagen
2.1. Git-Kommandos
2.2. Das Objektmodell
3. Praktische Versionsverwaltung
3.1. Referenzen: Branches und Tags
3.2. Versionen wiederherstellen
3.3. Branches zusammenführen: Merges
3.4. Merge-Konflikte lösen
3.5. Einzelne Commits übernehmen: Cherry-Pick
3.6. Visualisierung von Repositories
3.7. Reflog
4. Fortgeschrittene Konzepte
4.1. Commits verschieben – Rebase
4.2. Die Geschichte umschreiben – Interaktives Rebase
4.3. Wer hat diese Änderungen gemacht? – git blame
4.4. Dateien ignorieren
4.5. Veränderungen auslagern – git stash
4.6. Commits annotieren – git notes
4.7. Mehrere Root-Commits
4.8. Regressionen finden – git bisect
5. Verteiltes Git
5.1. Wie funktioniert verteilte Versionsverwaltung?
5.2. Repositories klonen
5.3. Commits herunterladen
5.4. Commits hochladen: git push
5.5. Remotes untersuchen
5.6. Verteilter Workflow mit mehreren Remotes
5.7. Remotes verwalten
5.8. Tags austauschen
5.9. Patches per E-Mail
5.10. Ein verteilter, hierarchischer Workflow
5.11. Unterprojekte verwalten
6. Workflows
6.1. Anwender
6.2. Ein Branching-Modell
6.3. Releases-Management
7. Git auf dem Server
7.1. Einen Git-Server hosten
7.2. Gitolite: Git einfach hosten
7.3. Git-Daemon: Anonymer, lesender Zugriff
7.4. Gitweb: Das integrierte Web-Frontend
7.5. CGit – CGI for Git
8. Git automatisieren
8.1. Git-Attribute – Dateien gesondert behandeln
8.2. Hooks
8.3. Eigene Git-Kommandos schreiben
8.4. Versionsgeschichte umschreiben
9. Zusammenspiel mit anderen Versionsverwaltungssystemen
9.1. Subversion
9.2. Eigene Importer
10. Shell-Integration
10.1. Git und die Bash
10.2. Git und die Z-Shell
11. Github
A. Installation
A.1. Linux
A.2. Mac OS X
A.3. Windows
B. Struktur eines Repositorys
B.1. Aufräumen
B.2. Performance

Kapitel 11. Github

Es gibt derzeit mehrere Hosting-Websites, die kostenfreies Git-Hosting für Open-Source-Projekte anbieten. Die mit Abstand bekannteste von allen ist Github.[138] Zwei andere bekannte reine Git-Hoster sind Gitorious[139] und repo.or.cz[140]. Aber auch bereits etablierte Hosting-Seiten wie Sourceforge[141] und Berlios[142] bieten mittlerweile Git-Hosting an.

Github wurde 2008 von Chris Wanstrath, P.J. Hyett und Tom Preston-Werner gegründet. Die in Ruby on Rails entwickelte Plattform hat über drei Millionen Nutzer und hostet über zehn Millionen Repositories. Auch wenn man bedenkt, dass viele dieser Repositories sogenannte Forks (Klone) anderer Repositories oder sogenannte Gists (Quellcode-Schnipsel) sind, ist das trotzdem eine beachtliche Anzahl. Viele namhafte Projekte verwenden heutzutage Github, um ihren Quelltext zu verwalten, unter anderem das Kommandozeilen-Tool Curl[143], das Web-Framework Ruby on Rails[144] und die JavaScript-Bibliothek jQuery[145].

Das kostenfreie Angebot umfasst unbegrenzte Git-Repositories – mit der Einschränkung, dass diese öffentlich verfügbar sind (Public Repositories). Zusätzlich bietet Github kostenpflichtige Optionen für Einzelpersonen und Firmen, die es erlauben, zugriffsbeschränkte Repositories (Private Repositories) anzulegen und zu nutzen. Großen Unternehmen bietet Github eine Lösung namens GitHub Enterprise an.

Github bietet alle wesentlichen Features, die Sie von einer Projekt-Hosting-Plattform erwarten, darunter auch Projekt-Wiki und Issue-Tracker. Das besondere daran ist aber, dass das Wiki-System Gollum[146] als Backend keine Datenbank, sondern lediglich ein Git-Repository verwendet. Als Markup bietet Github mehrere Syntax-Optionen⁠[147] an, unter anderem Markdown, Textile, Mediawiki und Asciidoc.

Der Issue-Tracker ist auf Git ausgelegt und listet auch über das Webinterface erstellte Pull-Requests. Zusätzlich wurde in den Issue-Tracker ein E-Mail-Backend eingearbeitet. Ihre Antworten auf die eingehenden E-Mails werden automatisch von Github verarbeitet und auch im Webinterface angezeigt. Was Github jedoch nicht anbietet, sind Mailinglisten – dafür müssen Sie auf Alternativen ausweichen.

Abbildung 11.1. Github-Seite von Gollum

bilder_ebook/github-gollum.png

In Abbildung 11.1, „Github-Seite von Gollum“ sehen Sie einen Ausschnitt der Projektseite von Gollum. Wichtig sind die Menüpunkte Source (Quellcode-Übersicht), Commits, Network (Forks des Projekts mit Änderungen), Pull-Requests, Issues, Wiki und Graphs (statistische Graphen). Andere wichtige Bedienelemente sind der Button Fork sowie Downloads und auch die Anzeige der Klon-URL.

Bei Github steht zunächst der Entwickler im Mittelpunkt: Repositories sind immer Usern zugeordnet. Das ist ein großer Unterschied zu etablierten Hosting-Plattformen, bei denen grundsätzlich die Projekte im Vordergrund stehen, und die Nutzer diesen untergeordnet sind. (Es ist aber auch in Github möglich, Projekt-Konten anzulegen, denen dann wiederum User zugeordnet werden – beliebt bei privaten Repositories und größeren Projekten.)

Github bietet viele Möglichkeiten, Veränderungen auszutauschen. Zwar ist es mit Github möglich, einen zentralisierten Ansatz (siehe Abbildung 5.1, „Zentraler Workflow mit verteilter Versionsverwaltung“) zu verfolgen, indem Sie Anderen Zugriff auf Ihre eigenen Repositories ermöglichen – die jedoch am meisten genutzte Form des Austausches ist eher ein Integration-Manager-Workflow (siehe Abbildung 5.8, „Integration-Manager Workflow“).

Abbildung 11.2. Workflow bei Github

bilder_ebook/github-workflow.png

  1. Ein potentieller Contributor forkt[148] ein Repository bei Github.
  2. Das öffentliche Repository wird wiederum geklont, Veränderungen werden eingepflegt.
  3. Commits werden in das öffentliche Repository hochgeladen.
  4. Dem Projekt-Autor wird ein Pull-Request geschickt. Diese können, wie bereits erwähnt, direkt im Web-Interface erstellt und verschickt werden.
  5. Der Autor lädt die Neuerungen aus dem öffentlichen Repository, überprüft, ob sie seinen Qualitätsansprüchen genügen und integriert sie ggf. per Merge oder Cherry-Pick lokal.
  6. Die Veränderungen des Contributors werden in das öffentliche Repository des Autors hochgeladen und verschmelzen so mit der Software.
  7. Der Contributor gleicht sein lokales Repository mit dem öffentlichen Repository des Autors ab.

Das Github Webinterface bietet einiges an Web-2.0-Komfort. So können Sie z.B. statt der Schritte 5. und 6. mit einem einzigen Klick direkt über das Webinterface einen Merge vollziehen. Selbstverständlich wird vorher überprüft, ob der Merge konfliktfrei bewerkstelligt werden kann – falls nicht, erscheint statt der Option zum Mergen eine Warnung.

Seit kurzem ist es auch möglich, die Schritte 1., 2., 3. und 4. vollständig im Webinterface durchzuführen. Dafür klicken Sie in einem fremden Repository auf den Button Fork and edit this file – das Repository wird automatisch für Ihr Benutzerkonto geforkt, und es tut sich ein web-basierter Editor auf, in dem Sie Ihre Veränderungen sowie eine Commit-Message eintragen. Danach werden Sie automatisch auf die Pull-Request Seite weitergeleitet.

Da Sie bei vielen Forks schnell den Überblick verlieren, stellt Github eine grafische Darstellung der Forks mit noch ausstehenden Änderungen bereit, den sogenannten Network-Graph:

Abbildung 11.3. Der Github Network-Graph

bilder_ebook/github-network.png

Github bietet Ihnen unter Graphs noch weitere Visualisierungen. Unter Languages wird angezeigt, welche Programmiersprachen das Projekt einsetzt. Die Grafik Impact (engl. Auswirkung) zeigt, welcher Entwickler wann und wie viel geleistet hat. Punchcard (Lochkarte) zeigt die Commit-Aktivität für Wochentage und Tageszeiten. Traffic (Verkehr) schließlich listet die Anzahl der Projektseitenaufrufe während der letzten drei Monate auf.

Wie das Motto Social Coding schon andeutet, hat Github mehrere Features, die Sie auch in sozialen Netzwerken finden. Zum Beispiel können Sie sowohl einzelnen Usern als auch Repositories folgen (engl. follow). Sie erhalten dann in Ihrem Dashboard (Armaturenbrett) über eine Art Github-Newsticker: Meldungen über neue und geschlossene Pull-Requests, neue Commits, die hochgeladen wurden, Forks usw. Die Newsfeeds der User und Repositories sind aber auch als RSS-Feed verfügbar, sollten Sie externe Newsreader vorziehen.

Ein kleines, noch relativ unbekanntes Projekt kann daher über Github sehr schnell bekannt werden, wenn eine kritische Anzahl an „Followern“ erreicht ist.

Github bietet auch einen Pastebin-Dienst an, den Gist (Kernaussage). Im Gegensatz jedoch zu anderen Pastebin-Diensten ist bei Github jeder Gist ein vollwertiges Git-Repository. Besonders für Code-Schnipsel ist dies eine interessante Neuerung.

Auch bei der Anbindung an externe Dienste leistet Github ganze Arbeit. Es gibt 50 sogenannte Service Hooks, mit denen Sie Nachrichten bzgl. eines Repositorys an externe Dienste weiterleiten. Dabei sind unter anderem altbewährte Klassiker wie E-Mail und IRC, aber auch modernere Alternativen wie Twitter und Jabber.

Github bietet aber noch zusätzliche „Gimmicks“, die sehr praktisch sind. So werden aus Tags automatisch Quellcode-Archive zum Herunterladen. Wie Sie in Abbildung 11.4, „Aus Tags erstellte Downloads“ sehen, sowohl als tar.gz als auch als .zip Archiv.

Abbildung 11.4. Aus Tags erstellte Downloads

bilder_ebook/github-download.png

Für Entwickler, die oft mit Bildern arbeiten, bietet Github sogenannte Image View Modes.[149] Sie zeigen Unterschiede zwischen zwei Versionen einer Grafik an, ähnlich dem in Abschnitt 8.1.3, „Eigene Diff-Programme“ vorgestellten Script. Es gibt folgende Modi:

2-up

Die zwei verschiedenen Versionen werden nebeneinander dargestellt, siehe Abbildung 11.5, „Modus 2-up. Auch Größenunterschiede sind ersichtlich.

Abbildung 11.5. Modus 2-up

bilder_ebook/github-image-diff-2up.png

Swipe

Das Bild wird in der Mitte geteilt. Links sehen Sie die alte Version und rechts die neue. Schieben Sie den Regler hin und her, um die Änderungen zu beobachten. Siehe Abbildung 11.6, „Modus Swipe.

Abbildung 11.6. Modus Swipe

bilder_ebook/github-image-diff-swipe.png

Onion Skin
Auch hier kommt ein Regler zum Einsatz, diesmal wird jedoch die neue Version eingeblendet, es entsteht also ein fließender Übergang zwischen alt und neu.
Difference
Zeigt nur die Pixel an, die verändert wurden.

Die Programmierer hinter Github feilen weiter am Webinterface und so kommen regelmäßig innovative Verbesserungen hinzu. Die Seite hat eine eigene Hilfe-Seite[150], auf der Arbeitsschritte mit dem Webinterface detailliert mit Screenshots erklärt werden.



[148] Nicht als Projekt-Fork misszuverstehen, bei dem sich ein Projekt aufgrund interner Differenzen spaltet.


Creative Commons License
Lizensiert unter der Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.