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”: 
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.
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:
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.
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.
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 ;) ).
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.
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.
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.
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.
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.
