Letzte Änderung am 28. Dezember 2021 by Christoph Jüngling
Immer wieder stößt man beim Stöbern in Open-Source-Projekten auf Adressen wie github.com und ähnliche. Dort findet man dann neben Downloadmöglichkeiten oder einem Wiki mit Informationen zu dem Programm auch den Quellcode.
Immer wieder heißt es dann auch, man könne an Open-Source-Projekten mitarbeiten, wenn man die Programmiersprache beherrscht, Zeit und Interesse hat und sich in die Programmstruktur hineinfinden kann. Das sind sicher nicht gerade kleine Hürden, aber generell: Wie macht man das?
Und manchmal heißt es auch, man könne sich ja den Sourcecode herunterladen oder sogar “clonen”, um ihn sich z.B. in einem Raspberry-Pi-Projekt zu nutze zu machen. Wie geht das?
In diesem Artikel
Git clone
Sucht man auf Github nach “Raspberry Pi”, dann bekommt man aktuell fast 47.000 über 55.000 Ergebnisse geliefert. In vielen Beschreibungen solcher Projekte habe ich Anweisungen wie die folgende gelesen (Quelle: Linux-Magazin):
Um den DVB-T-Stick als Empfänger einzusetzen, benötige ich zunächst das RTL-SDR-Paket, das
git clone git://git.osmocom.org/rtl-sdr.git
auf den Rechner holt.
Das “Problem” dabei: Den Befehl “git clone …” muss man auf der Kommandozeile ausführen. Im Falle des Raspi wird der Bastler sicher schon über entsprechende Anleitungen dahin geführt worden sein und hat hoffentlich die Berührungsängste mit der Kommandozeile abgebaut, falls diese überhaupt vorhanden waren.
Doch jenseits der Bastlerszene sind auch Situationen denkbar, in denen ein “normaler Windows-User” (die Polemik ist beabsichtigt) vor dem Problem steht, einen “Clone” oder sogar einen “Fork” machen zu müssen. Klären wir also zunächst mal die Begriffe.
Sowohl ein Clone als auch ein Fork ist zunächst die Kopie eines (in der Regel) kompletten Repositories. Im Falle von Git und anderen sog. “verteilten” Quellcodeverwaltungssystemen ist ein Clone immer die Vorstufe, um an einem Projekt mitzuarbeiten. Dabei wird das Repository vom Server auf die lokale Festplatte kopiert und ein Verweis zu der Quelle (bei Git “origin” genannt) eingefügt. So “weiß” der Clone, woher er kam und wohin die gemachten Änderungen “gepusht” werden sollen.
Von einem Fork spricht man, wenn die Entwicklung zum Beispiel einen anderen Weg einschlagen soll. Dies geschieht in Open-Source-Projekten dann, wenn ein Teil der Entwickler andere Vorstellungen von einer Weiterführung des Projektes hat als der Rest. So entstand z.B. LibreOffice aus OpenOffice vor einigen Jahren.
Von einem Fork wird jedoch auch dann gesprochen, wenn ein Entwickler etwas zu einem Projekt beitragen möchte, in diesem jedoch keine Schreibberechtigung hat. Dann würde ein “git push origin” fehl schlagen. Ein Fork ist technisch also ein Clone, der jedoch ein wenig anders benutzt werden muss. Für Git macht das keinen Unterschied, es gibt keinen Befehl “git fork”!
Arbeiten mit einem Fork
Ein Fork wird in der Regel bereits auf dem Server erzeugt, also z.B. auf Github, Gitlab oder Bitbucket. Dadurch entsteht in meinem eigenen Namespace eine Kopie des Projektes. Original und Fork werden dann miteinander verlinkt, es ist also ein vollkommen transparenter Prozess.
In dieser Kopie in meinem eigenen Account habe ich nun alle Möglichkeiten, vom Verändern, Ergänzen bis zum Löschen. Was ich tue, hat zunächst keine Auswirkung auf das Original-Projekt (außer dass beim Löschen der Link wieder entfernt wird). Anschließend clone ich dieses Repository aus meinem Bereich in meine lokale Festplatte und beginne mit der Entwicklung.
Bevor ich aber beginne, eine Änderung oder Ergänzung des Codes zu programmieren, lege ich sinnvollerweise einen Branch an (siehe Mein kleiner Git-Workflow). Diesen pushe ich, wann immer ich will, auf mein Repository.
Wenn ich dann fertig bin, erzeuge ich auf dem Server einen “Pull Request” (in Foren oft als “PR” abgekürzt). Damit teile ich dem Original-Autor mit, dass er sich bitte meinen Branch anschauen möge. Wenn dieser ihm gefällt, kann er ihn mit einem “Merge” in seinen aktuellen Stand integrieren. Er kann den PR aber auch ablehnen. In beiden Fällen erhalte ich auf der Weboberfläche des Code-Hosters eine entsprechende Mitteilung.
Wie auch immer nun das Ergebnis lautet, danach kann ich theoretisch das in meinem Namespace liegende Projekt wieder löschen. Oder ich behalte es, weil ich noch weitere Ideen habe …
Und der User?
Nun, der User, der das Projekt einfach nur auf seinem Raspi einsetzen möchte, macht nach dem “git clone” mit seinem Raspi-Projekt weiter. Ein Clone muss kein Fork werden, aber jeder Fork ist zunächst immer ein Clone.
Ganz einfach, oder?
Neueste Kommentare