Tag 4: Open Source Infrastruktur - GitHub

vom 4. December 2009

Open Source Projekte stützen sich nach Möglichkeit auch auf freie Tools. Dies hat den angenehmen Vorteil, dass jeder auch etwas mit dem freien Programmcode anfangen kann. Gerade von OSS wird sehr viel Software Engineering abverlangt, denn Projekte müssen nicht nur über Ländergrenzen hinweg funktionieren, sondern verlangen von den Teilnehmern noch viel mehr als man das von normalen Mitarbeitern in Software-Schmieden abverlangen würde. Dafür braucht es natürlich auch professionelle Tools.

Früher funktionierte das Fixen eines Fehlers und das anschließende Einreichen der Änderungen (man sagt hier auch "in den Upstream bringen" oder "einen Patch einreichen") etwas umständlich: Man lud sich den Programmcode von SourceForge.net herunter, machte seine Änderungen und erzeugte mit diff eine Datei, die die gemachten Änderungen enthielt. Diese Datei schickte man dem Ersteller der Software, der diese mit dem Programm patch in seinen eigenen Programmcode einspielte. So läuft es in vielen Stellen noch heute. Das Genie Linus Torvalds hatte für den Linux Kernel eine professionelle Lösung für dieses Problem geschaffen. git heißt das Programm und ist eine Versionsverwaltung der Generation 3.

GitHub ist ein freier Hosting-Dienst für git-Repositories mit einer schicken Oberfläche, die die Kollaboration noch einfacher gestaltet. Diesen Dienst werden wir verwenden. Also schnell einen Account anlegen und das Projekt advent2009 forken. (Ein "fork" eines Projektes ist eine Abspaltung vom Hauptentwicklungszweig in ein neues Projekt, meist mit "-ng" Postfix im Namen. Früher eine Schande für den Hauptentwickler, mit GitHub gewollt!) Somit habt ihr erst einmal eine exakte Kopie meines Projektes. Dieses Projekt muss jetzt auf die Platte. Aber eines vorweg: Allein entwickeln ist viel einfacher, man sollte deshalb den Mehraufwand nicht unterschätzen. Aber wer die komplexen Tools einmal beherrscht, erkennt wie sie den Prozess verbessern und beschleunigen.

Ach ja, ich hatte vergessen zu erwähnen, dass ich hier davon ausgehe, dass ihr eine vernünftige Console habt. Unter Linux und OSX 10.x sowieso, für Windows gibt es Cygwin.

Also, ist ein Fork des Projektes angelegt, wird es mit der git@ URI geclont

git clone git@github.com:/deinName/advent2009.git

Danach ist es ratsam, den Upstream als entfernten Branch mit aufzunehmen. Der Upstream ist in diesem Falle das Projekt von mir.

git remote add upstream git://github.com/aaronmueller/advent2009.git
git fetch upstream

Ein "git branch -va" zeigt nun alle Branches an. Nun können wir Änderungen vornehmen. Die Änderungen selbst zeigt uns "git diff" an. Mit "git status" sehen wir die Dateien, die hinzugekommen, entfernt oder geändert wurden. Alle Äderungen, die commited werden sollen, müssen zuerst hinzugefügt werden, "git add " erledigt dies. Nachdem man mit "git commit -va" einen lokalen Commit durchgeführt hat, läd man die Änderungen auf den Github server mit "git push origin master" wieder hoch. Auf Github sind nun die Änderungen für alle sichtbar.

Jetzt kommt wieder Github ins Spiel, was uns ein tolles Kollaborationsfeature bietet. Bei jedem Projekt auf Github gibt es einen Button, der sich "pull request" nennt. Drückt man diesen, kann man die gemachten Änderungen an den Hauptentwickler melden. Macht dies, wenn ihr Änderungen an mich schicken wollt. Traut euch, davon lebt Open Source!

Ein weiteres wichtiges Feature ist das Holen von Änderungen vom Hauptentwicklerzweig. Dazu kann man "git pull upstream master" verwenden. Dies holt die Änderungen aus dem Upstream und bindet es in den eigenen master ein.

Diese Basics sollten nun ausreichen um git in den Grundzügen zu bedienen. Wie man schon merkt, ist git ein sehr mächtiges und komplexes Tool. Es besteht aus über 100 kleinen Tools mit jeweils dutzenden von Optionen. Es braucht etwas Zeit bis man die Befehle verstanden und verinnerlicht hat, doch es lohnt sich - nicht nur für den Lebenslauf.

Übermorgen werden wir uns mit der Programmiersprache C und gcc beschäftigen, wir werden ein eigenes Makefile schreiben und damit den Buildprozess automatisieren. Gibt es Fragen oder Probleme? Dann fleißig die Kommentarfunktion nutzen.

delicious bookmark del.icio.us, Früher funktionierte das Fixen eines Fehlers und das anschließende Einreichen der Änderungen (man sagt hier auch \"in den Upstream bringen\" oder \"einen Patch einreichen\") etwas umständlich: Man lud sich den Programmcode von SourceForge.net herunter


Kommentare


Ruben am 4. December 2009
Schöne Einführung! Hier noch einen Link für die Einsteiger: http://gitcasts.com

Bin gespannt auf C. :)

nougad am 4. December 2009
Also Git ist Super! Keine Frage. Aber Github stehe ich etwas skeptisch gegenüber:

Zum einen ein proprietärer Closed Source Dienst. Ich denke ich muss dazu nichts mehr sagen. Zudem beschneidet es die Möglichkeiten die einem GIT bietet. Vor allem die Möglichkeit ein rebase zu machen fehlt finde ich sehr. Auch wenn ich weiß das man in public-repos auf ein rebase verzichten sollte möchte ich trotzdem so ein mächtiges Feature nicht ungenutzt lassen.

Aaron am 4. December 2009
Ja, das mit dem rebase ist nicht sonderlich schön. Allerdings auch verständlich. Wenn man Änderungen an der History zulassen würde, dann gäbe es auf github das totale Chaos und bspw. die Fork-Queue würde nicht mehr wirklich funktionieren.

GitHub und Closed Source: Ich hab bis jetzt keinen besseren freien Hosting Service für git Repos gefunden.

nougad am 4. December 2009
Naja also eine zweite Hostingseite mit einem vergleichbaren Funktionsumfang wie github gibts meines Wissens nicht. Vor allem die Community-Funktionen machen gibhub eben zu dem was es ist. Allerdings Hosting Seiten für Git Repos gibts mehr als genug.

Populärstes Beispiel http://gitorious.org/ was echt nett aussieht. Auch oft genutzt wird http://repo.or.cz/ was eben etwas minimalistischer ist. Sourceforge, rubyforge, Savannah, BerliOS etc ziehen ebenfalls nach und bieten Git Support an.

Somit ist das Hosting allein kein Alleinstellungsmerkmal mehr. Viel mehr die Communitiy Funktionen machen github so unglaublich erfolgreich.

kb am 8. December 2009
Für Windows git es msysgit. Ich hab sehr gute Erfahrungen damit gemacht. Man hat gleich noch eine Bash wo man die Befehle eingeben kann. http://code.google.com/p/msysgit/

Probleme gibt es nur, wenn einzelne object-files oder was mit gc aufgeräumtes > 2gb ist.