23 June 2014 GIT, GitHub, OSS Robert Muehsig

Auch im .NET Lager gibt es Bewegung im OSS Bereich und es gibt verschiedene Arten wie man bei einem Open Source Projekt “Contributed”.

Was zählt alles zu “Contribution”?

Unter “Contribution” läuft eigentlich alles – ob es Fragen/Probleme zu dem Projekt via Issues ist oder Dokumentation nachreicht oder ob man darüber bloggt oder das Projekt vorstellt. Solange man das Projekt damit irgendwie “vorran” bringt ist das alles super. Aber wie man wirklich Code hinzufügt zeige ich jetzt mal am Beispiel der NuGet Gallery.

GitHub

Es gibt unzählige Projekte auf GitHub und das was GitHub besonders gut macht ist die “Vernetzung”. Es ist eigentlich kinderleicht bei einem Projekt auf GitHub mitzumachen und selbst wenn man (wie ich ;) ) kein Git-Guru ist geht fast alles auch bequem über die UI.

Code Contribution mit GitHub

Wichtigster Punkt hierbei ist, dass man sich genau die “Contribution Guideline” durchliesst. Die meisten Projekte besitzen solch eine Anleitung – meist findet sich dies in der ReadMe oder es gibt eine Contribution Datei.

Contribution Guideline

Bei der NuGet Gallery findet man die Datei hier. GitHub verweisst auch beim Mergen eines Pull Requests auf diese Datei hin.

Schritt 1: Issue suchen

Um einen ersten Schritt zu machen ist es gut wenn man sich z.B. bei Up-for-Grabs.net ein Projekt sucht und sich da ein passendes Issue vornimmt.

Bei der NuGet Gallery gibt es den Milestone “Up for Grabs”: image

Issue gefunden? Dann gehts los… wie immer gilt: Kommunikation ist alles – bei einem größeren Change empfiehlt es sich zu schreiben was man vor hat.

image

 Schritt 2: Ein Fork erstellen

Um bei dem Projekt mitzumachen muss man einen eigenen Fork erstellen. Dies geschieht über diesen Knopf bzw. kann man auch alles via Kommandozeile erledigen:

image 

Wer bereits einen Fork hat, der kann es mit den simplen Commands aktualsieren (evtl. geht dies auch via GUI, hab ich aber nicht rausbekommen).

# Add the remote, call it "upstream":

git remote add upstream https://github.com/whoever/whatever.git

# Fetch all the branches of that remote into remote-tracking branches,
# such as upstream/master:

git fetch upstream

# Make sure that you're on your master branch:

git checkout master

# Rewrite your master branch so that any commits of yours that
# aren't already in upstream/master are replayed on top of that
# other branch:

git rebase upstream/master

# Update the fork
git push -f origin master

Der Command stammt von dieser Stackoverflow Antwort.

Zwischenschritt: GitHub for Windows installieren

Der GitHub for Windows Client ist ausgezeichnet für Leute die sonst keine Ahnung von Git haben. Da mein Kommandozeilen Voodoo leider nicht ausreicht, zeig ich nur die Variante via GUI ;)

Schritt 3: Branch erstellen

Wer potenziell mehrere Issues beheben möchte, der sollte ein Branch in seinem Fork erstellen. So kann man den Master stehts aktuell halten und trotzdem an den diversen Issues seperat arbeiten. Empfehlenswert ist natürlich vom Naming her etwas zu wählen was mit dem Issue zutun hat.

image

Schritt 4: Änderungen machen und “comitten”

Wenn man denkt die Änderungen sind gemacht und das Issue ist damit behoben kann man einfach seine Änderungen zu seinem Branch comitten.

image

Schritt 5: Branch publishen

Nun kann man den Branch publishen (man kann ihn eigentlich auch schon vorher publishen – aber bei kleinen Änderungen bin ich auch so durch gekommen ;) ).

image

 Schritt 6: Pull Request (PR) erstellen

Nach dem “publishen” stellt GitHub fest dass es ein Branch gibt und das man diesem dem eigentlichen Projekt via “Pull Request” auch anbieten kann.

image

Schritt 7: PR beschreiben

Als Hilfreich für den “Owner” ist es wenn man genauer ausführt was man eigentlich gemacht hat und das man natürlich auch das Issue erwähnt.

image

Schritt 8: Warten auf den “Merge”

Jetzt liegt es in der Hand des Owners was er mit dem PR macht – entweder wird es gemerged oder halt nicht, wobei wenn man nicht alles falsch gemacht hat, dann sind die meisten Projekte sehr froh über jeden PR.

image

Schritt 8.1: Eventuelle Verbesserungen des PRs durchführen

Bei meinem PR gab es noch Anmerkungen. Man kann dann einfach die Änderungen auf seinem Fork / Branch machen und wieder zu GitHub überführen – der Pull Request wird automatisch auf die neuste Version aktualisiert.

image

Finale

Wenn alles gut läuft wird der PR gemerged.

Neben der Erfahrung und dem guten Gefühl gibt es auch etwas Internet Fame :-)

Ich hoffe ich konnte den einen oder anderen animieren – mein dank möchte ich nochmal an Adam Ralph aussprechen der mit seinem “Get Involved” Talk mich motiviert hatte.


Written by Robert Muehsig

Software Developer - from Dresden, Germany, now living & working in Switzerland. Microsoft MVP & Web Geek.
Other Projects: KnowYourStack.com | ExpensiveMeeting | EinKofferVollerReisen.de

If you like the content and want to support me you could buy me a beer or a coffee via Litecoin or Bitcoin - thanks for reading!