Aaron Fischer Ingenieur, Vater, Heimwerker, Problemlöser

03 Dezember, 2009

Tag 4: Open Source Infrastruktur - GitHub

TL;DR:

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 Änderungen, 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ädt 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-Branch 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.