Von Gitea nach Gitlab

In der heutigen Zeit hat sich immer mehr durchgesetzt, Softwareprojekte mithilfe einer Versionierungssoftware zu entwickeln. Vorteile gibt es dabei tatsächlich nicht nur für Teams. Auch „Soloprojekte“ können von einer solchen Versionierung profitieren. Am Markt gibt es sehr verschiedene Systeme und dann stellt sich noch die Frage: Selbst hosten oder lieber einen Account bei einem größeren Anbieter nutzen? Ein Komplettüberblick für alle Varianten mit allen Vor- und Nachteilen kann es nicht geben. Wir wollen aber an dieser Stelle unseren Weg aufzeigen und vielleicht auch dokumentieren, warum der Anfang zwar gut war, bald aber nicht mehr so praktikabel.

Ausgangssituation

Aktuell gibt es bei uns nur „Soloprojekte“ also Projekte, bei denen ein Entwickler sich um die Programmierung innerhalb des Projektes kümmert. Perspektivisch könnte es aber auch passieren, dass so ein Projekt mit anderen zusammen bearbeitet wird – sei es Externen oder aber auch interne Mitarbeiter. Deswegen wurde zwischendurch beschlossen, für alle Projekte bereits eine Versionierung aufzusetzen. Auch mit dem Hintergrund, dass es immer mal wieder vorkommt, dass eine gewünschte Änderung dann doch nicht das passende für den Kunden ist. Das ist mit der Versionierung kein Problem: Richtig aufgesetzt kann man eine Änderung rasch zurücknehmen und bekommt einen sauberen Stand – ohne sich Gedanken machen zu müssen, ob man jetzt noch eine Codezeile vergessen haben könnte.

Der Anfang: selbst gehostet oder bei einem Anbieter?

Ok, der Wunsch war also da: Es sollte eine Versionierung eingeführt werden. Doch damit kamen erst mal die Fragen. Welches System passt überhaupt? Und danach: Wird ein großer Anbieter genutzt oder wird das auf einem eigenen Server selbst gehostet? Gleich vorweg: Wir haben uns fürs selbstgehostete Modell entschieden. Warum? Auch weil es ein bisschen mehr Kontrolle darüber liefert, wo die Daten liegen… Stichwort DSGVO und Co. Aber der Reihe nach.

Schnell war hier klar es sollte etwas wie „git“ sein. Weithin bekannt und auch schon aus anderen Projekten und der Beschäftigung als Angestellter vertraut. Damit waren die Variationen schon mal eingeschränkt. Nach kurzer Recherche war dann auch klar, dass mit Gitea eine „Git-Version“ bereitsteht, die einfach zu installieren ist und damit perfekt geeignet für eine selbstgehostete Variante. Da auf dem passenden Server sonst nichts weiter laufen sollte an zusätzlichen Services haben wir also einen „nackten“ Server aufgesetzt, mit den notwendigen Dingen wie Apache, Datenbank und Co ausgestattet und Gitea darauf eingerichtet. Anschließend konnte nach Einrichtung der SSH Keys und eines Tortoise Git Systems auf dem eigenen Windowsrechner sofort mit dem Anlegen und Versionieren unserer Projekte begonnen werden.

Was bietet Gitea?

Kurz zusammengefasst: Gitea fußt auf der git-Software auf, ist aber bewusst etwas schlanker gehalten. Einige Randfunktionen bietet Gitea nicht, das war aber zu dem Zeitpunkt kein Problem. Es ging ja nur erst mal darum, etwas zu Versionieren. Und das kann Gitea genauso wie Gitlab oder andere Softwares dieser Art. Selbst mit Branches und Merges hat Gitea kein Problem. Wirklich? Naja nicht ganz. Bei den Branches gibt es schon die erste Einschränkung.

Erste „Probleme“ mit Gitea…

Branches kann Gitea aber bei den Merge-Requests geht nur Sekt oder Selters. Heißt konkret: Ein Branch kann mittels Merge-Requests nur in seiner Gesamtheit abgelehnt oder angenommen werden. Es ist nicht möglich, einige Änderungen in den Hauptpfad zu committen und andere zurückzuweisen. Wir haben das auch festgestellt, als auf einmal in einem Projekt vollkommen unvermittelt noch ein weiterer Externer Programmierer vom Auftraggeber zugelassen wurde und es auf einmal darum ging, die eigenen Änderungen mit den Änderungen des Kollegen so zusammen zu bekommen, dass am Ende alles erhalten blieb, was notwendig war. Wir haben das hier versucht über eben einen Branch, in dem erst mal die Änderungen des Anderen eingespielt wurden und dann sollte über einen Merge-Request das ganze vereinigt werden. Gitea zeigte auch brav alle Änderungen an. Aber eine Funktion, die die Übernahme bestimmter Änderungen zuließ während anderes nicht übernommen würde gab es nicht. Eben Sekt oder Selters. 😉

Das war dann jedenfalls für uns der Moment, nochmal zu überdenken, ob ein Gitea wirklich weiterhelfen kann. Aber was gibt es für Optionen?

Ein Seitenblick: Gitlab vs. Gitea

Wie bereits erwähnt fußen mehrere Angebote auf git auf. Am bekanntesten neben Gitea dürfte Gitlab sein. Etwas mächtiger in den Funktionalitäten und etwas schwieriger aufzusetzen. Wir haben uns daran gewagt und werden in einem weiteren Post nochmal versuchen zusammenzufassen, auf was besonders geachtet werden sollte.

  • WordPress Plugins II: Ich klick mir die Welt

    WordPress (und auch andere CMS) sind verlockend: Schnell installiert, schnell mit Plugins erweitert und schnell online im Netz. Es ist aber leider etwas mehr als ein Pippi Langstrumpf Abenteuer bei dem 3×3 = 6 ergibt…

  • WordPress Performance: Warum zu viele Plugins deine Seite ausbremsen

    WordPress erfreut sich seit Jahren großer Beliebtheit – trotz oder vielleicht gerade wegen seines Alters. Heute wird damit fast alles gebaut: vom persönlichen Blog über Vereinsseiten bis hin zu ausgewachsenen Shopsystemen. Ursprünglich war WordPress aber eine reine Blogsoftware. Viele WordPress‑Seiten werden langsam, weil zu viele Plugins geladen werden – oft ohne dass Betreiber es merken.…

  • PHP Warum truthy Prüfungen nicht immer wahr sind

    In PHP – wie natürlich auch in anderen Programmiersprachen – gibt es verkürzte truthy-Prüfungen. Ob, wie und wann man sie einsetzt muss aber genau überlegt sein. Das hilft am Ende nicht nur der Lesbarkeit sondern vermeidet auch Bugs, die auf Grund falsch gedachter oder vermeintlich logischer Prüfungen aufkommen.

  • HTTP 500: Fehler – nur welcher?

    Neulich haben wir schon über den Unterschied zwischen 401 und 403 gesprochen. Jetzt wollen wir weiterschauen: der HTTP Code 500 ist ein weiterer häufiger Kandidat – und verhält sich „mysteriös“. Teilweise ist das aber auch gut so.

  • PHPUnit-Tests: Wenn ein roter Test ein Erfolg ist

    Ein roter PHPUnit‑Test bedeutet nicht automatisch, dass etwas kaputt ist. Manchmal zeigt er sogar, dass alles genau so funktioniert, wie es soll – zum Beispiel, wenn eine neue Auth‑Schicht greift. Ein kleiner Einblick in unsere modulare Vorgehensweise und warum ‚rot‘ nicht immer schlecht ist.

Kommentare

Kommentar verfassen