Git-Tutorium – Teil 4: GitHub

Arbeiten mit zwei Remote-Repositories

Wenn man regelmäßig zu einem Projekt über GitHub beiträgt, bietet sich eine lokale Konfiguration an, die das Arbeiten mit zwei Remote-Repositories erleichtert. Dadurch, dass man letztendlich mit zwei Repositories arbeitet, müssen beide korrekt verwaltet werden. So gibt es einmal das eigene Repository, in dem man Schreibrechte besitzt, und das Repository des Projektes, wohin die Pull-Requests und auch anderen Änderungen des Projektes fließen. Man sollte daher immer beachten, dass man sein eigenes Repository auf dem eigenen Stand hält.

Wenn man die oben aufgelisteten Befehle ausgeführt hat, ist der eigene Fork als Remote-Repository origin konfiguriert. Dies sollte man genau so belassen, da man alle Branches in das eigene Repository pusht. Jetzt sollte man das Repository des Projektes ebenfalls als Remote-Repository hinzufügen. Hier bietet es sich an, es upstream zu nennen, da es sich schließlich um das Upstream-Projekt handelt.

$ git remote add upstream git@github.com:svijee/drunken-nemesis.git

Jetzt ist zwar das Repository konfiguriert, allerdings sind die Änderungen noch nicht heruntergeladen. Dies kann man mit einem der beiden aufgeführten Befehle durchführen:

$ git remote update
$ git fetch upstream

Während der erste Befehl alle Remote-Repositories herunterlädt, lädt letzterer Befehl nur das Remote upstream herunter. In der Regel ist es nun so, dass sich auf dem Upstream-Repository einiges tut, diese Änderungen müssten dann regelmäßig in das eigene Repository übernommen werden. Dazu sollte man regelmäßig git remote update oder git fetch upstream ausführen und anschließend den Branch aus dem Remote-Repository in den Branch des eigenen Repositorys mergen. In diesem Beispiel ist es der Branch master, den man aktualisieren möchte:

$ git merge upstream/master

Sofern keine Änderungen auf dem Branch master im eigenen Repository sind, sollte der Merge problemlos funktionieren. Änderungen, die man dem Haupt-Repository beifügen will, sollte man daher immer in einem neuen Branch anlegen, um Merge-Konflikte zu vermeiden.

Häufig passiert es aber auch, dass man Pull-Requests anlegt, die zu einem späteren Zeitpunkt nicht mehr automatisch ohne Konflikte gemergt werden können. Als Einreicher von Pull-Requests sollte man also immer darauf achten, dass der Pull-Request ohne Konflikte gemergt werden kann. Da dies nicht immer möglich ist, müssen gegebenfalls Commits aus dem Entwicklungsbranch des Haupt-Repositorys übernommen werden. Diese kann man entweder mit dem git merge-Befehl mergen, schöner ist es allerdings, wenn man ein Rebase durchführt, was im dritten Teil dieses Tutoriums erläutert wurde.

Weitere Funktionen von GitHub

GitHub bietet nicht nur das Hosten von Repositories an. Die Funktionen sind mittlerweile vielfältig und decken so gut wie alle Wünsche ab, die man an ein Software-Projekt haben kann. Darunter ein Ticket-System (»Issues«) und ein Wiki. Beide sind direkt über das Repository zu erreichen. Daneben kann man auch statische Webseiten mit GitHub-Pages hosten oder Gists als Lager für einzelne Dateien anlegen.

Alternativen

GitHub ist nicht die einzige Plattform, welche das Hosten von Repositories mit sinnvollen Features erweitert, um einfach und kollaborativ an Projekten zu arbeiten. So hat GitHub auch Nachteile, etwa steht es selbst nicht unter eine Open-Source-Lizenz und das Hosten von privaten, nicht öffentlichen Repositories kostet Geld.

Als Alternativen gibt es Gitlab und Bitbucket, bei denen man auch private Repositories mit Einschränkungen kostenlos hosten kann. Gitlab kann man aber auch selbst auf eigenen Servern hosten, sodass man für den Firmen-internen Gebrauch von Closed-Source-Software den Quellcode nicht auf fremde Server hochladen muss.

Autoreninformation

Sujeevan Vijayakumaran (Webseite) nutzt seit drei Jahren Git als Versionsverwaltung.

Dieser Artikel ist in freiesMagazin 06/2015 (ISSN 1867-7991) erschienen. Veröffentlichung mit freundlicher Genehmigung.