Github – Pull Requests aktuell halten


Flattr this

Motivation

Auf Github kann jeder Nutzer auf einfachster Weise einen Fork von seinem Lieblingsprogramm erstellen und nach Lust und Laune auf diesem die gewünschten Features selbst implementieren. Sind diese fertiggestellt werden sie als Pull Request an den eigentlichen Projektowner gesendet.

In der Regel war dieser aber auch nicht untätig und hat sein Projekt auch weiterentwickelt. Oder er ist gerade mitten in der Entwicklung eines neuen Features und so bleibt der Pull Request eine ganze Weile liegen. In der Zeit häufen sich die Commits des Projektowners und der Stand auf dem der Pull Request basiert ist hoffnunglos veraltet.

Jetzt erst sieht der Projektowner den Pull Request und versucht in zu integrieren – doch leider hat sich das Projekt soweit weiter entwickelt, dass viele Versionskonflikte auftreten. Das möchte sich der Owner nicht antuen und fordert vom Ersteller des Pull Requests das er diesen bitte zunächst mit dem aktuellen Versionsstand abgleicht. Doch wie geht das? Genau das soll hier kurz beschrieben werden.

Vorraussetzungen

Bevor man einen Pull Request auf Github stellen kann, hat man in der Regel das Original Repository auf Github geforkt und davon einen Klone auf seinen lokalen Rechner gezogen.

Will man nun ein neues Feature implementieren sollte unbedingt ein neuer Branch für die Entwicklung des Features abgespalten werden. Dies hat den Vorteil, das man zeitgleich an verschiedenen neuen Features arbeiten kann ohne von der Fertigstellung oder der erfolgreichen Integration eines Features abhängig zu sein. Außerdem hält man sich so auch den master für eine stets lauffähige aktuelle Version frei. Letzteres ist gut, da es immer wieder mal Situationen gibt in denen man die gerade implementierte Lösung nach Fehlern durchsucht und dann ein Vergleich mit einer aktuellen, lauffähigen Version sehr hilfreich sein kann. Generell gilt aber auch auf Github pro Branch ist nur ein Pull Request möglich.

Aktualisierung des Branches

Die Lösung besteht im Prinzip darin bei der Entwicklung möglichst frühzeitig die neuen Änderungen des Owners in den eigenen featurebranch zu integrieren. Hierzu erzeugen wir uns einen Alias upstream im lokalen Git Repository.

(alles in eine Zeile schreiben, der Browser zeigt hier gern 2 Zeilen an)

git remote add –track master upstream git://github.com/owner/projectname.git

evtl. reicht auch die einfachere Variante

git remote add upstream git://github.com/owner/projectname.git

Als Werte für owner und projectname werden die Angaben des originalen Repositories verwendet von dem wir selbst unseren fork gezogen haben. Damit steht uns ein Alias für den Fetch bereit und diesen nutzen wir auch gleich. Wir befinden uns also aktuell im lokalen Projektverzeichnis und arbeiten auf dem Branch (also der Branch ist lokal ausgecheckt und in der Regel von uns auch schon editiert). Jetzt holen wir uns die Neuigkeiten vom Original Repository:

git fetch upstream

Wenn das funktioniert hat und das sollte immer funktionieren oder ihr habt Euch vorhin verschrieben oder das Internet ausgeschaltet, dann mergen wir die Neuigkeiten in unseren lokalen branch mit:

git merge upstream/master

oder die Variante ohne Auto Commit

git merge upstream/master –no-commit –no-ff

So jetzt noch ein bischen Konflikte lösen😉 committen und falls nötig den Pull Request aktualisieren bzw. bitte auch dokumentieren. Kommunikation ist alles und hilft dem Projektowner bei der Bewertung und Einarbeitung Eures Pull Requests.

Also Happy Pulling🙂

Und falls doch mal was schief geht und der ganze Branch zurück auf „Null“ – dem Stand des originalen Repositories – gebracht werden soll? Dann sollten diese Befehle helfen

git remote add upstream git://github.com/wp-cli/wp-cli.git (nur wenn wir den alias oben nicht schon angelegt haben)
git fetch upstream
git branch backup
git reset –hard upstream/master
git push –force

Damit habt ihr den aktuellen Branch zurück gesetzt.

Bei neueren Git Versionen scheint das Rücksetzen auf den upstream (er muss schon mit git remote add gesetzt wurden sein) wie folgt zu funktionieren:

git rebase –onto upstream/master

Diese Variante würde ich immer vorziehen, weil damit auch bereits veröffentlichte Dinge bearbeitet werden können.

 

Für Hinweise, Tipps, Anmerkungen und Kommentare bin ich stets dankbar.

 

Quellen:

http://gun.io/blog/how-to-github-fork-branch-and-pull-request/

http://scribu.net/blog/resetting-your-github-fork.html

http://www.senaeh.de/git-prinzip-beispiele/

Post a comment or leave a trackback: Trackback URL.

Kommentare

  • Johng522  On 24. August 2014 at 03:53

    Thanksamundo for the post.Really thank you! Awesome. ggegcbcdeaga

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: