 Zum Kongress habe ich mir überlegt, über was kann man denn erzählen und da ist mir ein Tool eingefallen, was ich für meine Arbeit benutze schon seit Jahren und was ich eigentlich vom Design her genial finde, nämlich Githair. Githair ist eine Verwaltungssoftware für Githreposities. Dazu kommen wir später. Ich will so eine Einführung machen, ganz kurz im Gith, weil ich weiß, dass zwar fast jeder Gith kennt, aber es gibt immer wieder Leute, die das nicht benutzen und stattdessen weiß ich nicht, mit irgendwelchen USB-Sticks arbeiten. Gith ist eine Versionsverwaltung, ähnlich Subversion, Bitkeeper und anderen Versionsverwaltungen, die halt acht gibt auf den Sourcecode, auf die Projekte. Gith wurde entwickelt von Linus Torwald und zwar, weil Bitkeeper die Lizenzen irgendwie geändert hatte und Linus Torwald ein vernünftiges System brauchte, um die Kernalverwaltung laufen zu lassen. Gith basiert vor allen Dingen darauf, dass man mit einem Server arbeitet, wo die Reposities liegen und dass man verteilt arbeiten kann. Das heißt, es gibt halt Leute oder Teams, können entsprechend Komits machen und ja, so weit ist es bekannt. Vielleicht kurz zu den Vorteilen von Gith gegenüber anderen Versionsverwaltungen. Es ist relativ stabil, es ist sicher und vor allen Dingen sehr effizient. Also Gith selber heißt Blödmann oder Blöd, weil es ist halt sehr einfach. Es besteht aus sehr wenigen Kommandos. Es ist optimiert für das verteilte Arbeit mit Gruppen. Es ist relativ einfach zu installieren. Jeder, der auf der Konsole arbeitet, kann halt mit wenigen Befehlen ein Repositie erstellen und das dann auch bedienen, weil es gibt nur eine Handvoll Befehle. Das eine ist der Innettbefehl. Es ist klar, erstelle Repositie dann oder die meisten werden es so machen. Die werden sich ein Repositie runterladen erst mal, was bereits im Netz existiert und dann damit arbeiten. Dann gibt es ad Dateien hinzufügen, commit senden, push, also nicht commit senden heißt indis Repositie entsprechend einspeichern, push zum Remote Server senden, pull vom Remote Server übertragen. Ich habe hier eine Folie mit kleinen Befehlen. Man sieht, das sind nicht allzu viele. Ich habe in den Vortragsunterlagen habe ich da noch eine Datei hinzugefügt. Die stammt auch nicht von mir, aber ich finde die eigentlich sehr einfach und die macht deutlich, dass man dann nicht studieren muss. Vielleicht noch mal was zum Thema best practices mit Git. Ich finde es sehr wichtig, weil ich habe am Anfang war ich so naiv und habe immer alles geedet mit dem Resultat. Ich hatte riesige Reposities, wo teilweise, was ich nicht Magento Shops drauf waren oder irgendwelche WordPress-Installationen halt komplett drauf waren. Das heißt, man sollte sich seine Reposities vernünftig einrichten. Das gilt vor allen Dingen für die Git-Ignore-Sachen, dass man sollte sich vielleicht ein Template erstellen für Git. Da komme ich gleich bei GTR noch zu. Man sollte Branches sinnvolle einsetzen. Vielleicht ein Beispiel. Also Branches sind quasi Verzweigung, Kopien, die weiterentwickelt werden können, parallel zu einem Hauptstrang. Meistens wird es so benutzt, dass man halt ein Stable-Release hat und ein Entwicklungs-Release und dann irgendwann sagt, okay, wir fressen das jetzt und packen das zurück in das Stable-Release. Ich mache das unter anderem so, dass wir als Datenbank-Projekte haben, die für mehrere Kunden sind. Und dann mache ich für jeden Kunden einen eigenen Branch, weil die natürlich eigene Vorlagen bekommen und eigene Änderungen bekommen. Und da kann man gut mit Branches arbeiten. Da sollte man sich auf jeden Fall mit beschäftigen. Diploi-Key sind wichtig. Man kann natürlich, wenn man sich beim Remote-Server anmeldet, jedes Mal ein Passwort eingeben. Aber so ein Diploi-Key ist einfach wesentlich einfacher und da reicht es tatsächlich, über Open SSH ein Key zu generieren und den dann zu hinterlegen. Das geht mit GTA sehr gut. Ja, so andere Sachen. Es gibt immer ganz viele Tipps dazu. Einige Leute sagen, nicht alles immer committen. Man sollte auf jeden Fall pushen, nur Änderungen, die man vorher geprüft hat, damit nicht tausende von Commits dazwischen sind. Und man sollte die Commits natürlich ordentlich kommentieren, damit man nachher noch mal weiß, wo man gerade dran gewesen ist. So, jetzt kommen wir auch zu Selbst-Toasten von Repositives. Einer der Gründe, weshalb ich mir GTA damals zugelegt habe, ist einfach die Tatsache, dass mir GitLab nicht gefallen hat. Ich arbeite kommerziell. Das heißt, ich kann nicht nur mit Open Source Archiven arbeiten und müsste dafür Geld bezahlen. Das Zweite ist, dass GitHub übernommen worden ist von Microsoft und das ist auch etwas, was man ja unter Umständen nicht machen will. Es gibt Git Alternativen zu GTA. Es gibt einmal das GitLab. Das ist basiert auf Ruby, ist dementsprechend komplex in der Einrichtung und ist im Grunde genommen als Alternative zu GitHub groß geworden. Das heißt, GitLab ist auch ein Online-Service, den ich quasi nutzen kann, ohne dass ich den selbst hosten muss. Es gibt allerdings auch eine Installation darauf. Gox ist wie GTA auch in Go geschrieben. GTA ist ein Fork, der hat sich allerdings weiter, weil er weiterentwickelt und bietet auch wesentlich mehr Features. Ich habe jetzt hier mal Fabricator mit aufgenommen. Ich habe mal versucht es zu installieren. Es geht nicht. Es ist wieder ein Mix mit verschiedenen Sachen. Mal gucken, wie viel Zeit ich habe. Das geht aber gut. Vielleicht Grundsätzliches. GTA ist natürlich Open Source, ist in Go geschrieben, benutzt in Frontend Node.js. Es läuft entsprechend unter fast allen Systemen, also auch unter Windows, Mac OS, ARM und so weiter und so fort. Das heißt auf dem Raspberry, es bezeichnet sich selbst als Painless. Painless heißt, die Installation braucht keine Abhängigkeiten. Man hat ja das normalerweise, wenn man GitLab installiert, muss man dann Wiki installieren, muss noch Tausende von Tools und Libraries installieren. Das ist nicht jedermanns Sache. Also im besten Fall braucht man tatsächlich nur Git. Das sollte auf jedem Rechner ohne weiteres installiert sein, vor allen Dingen auf einem Linux-Rechner. Dann braucht man Open SSH und natürlich eine SQL-Datenbank, MySQL oder Postgres SQL. GTA hat aber auch eingebaut Support für SQLite. Gut, vielleicht fange ich mal an mit den Features. Die zeige ich mal. Einfach an einem Beispiel. Ich hoffe, ich komme da überhaupt drauf. Ich sehe leider nur meine. Das Problem ist, ich sehe, also das ist mein privates Git Repository. Ich habe da viele oder mein privates Git, GTA, was ich eingerichtet habe. Ich habe da auch einige Open Source Repositories, die das GTA selber ist relativ moderat, was so die Hardware-Anforderungen angeht und läuft halt so mit einer Web-Oberfläche. Der Vorteil von GTA ist, es kommt als ein Archiv. Das heißt, alles, was wir hier sehen, die, ich gehe mal auf den Open Source, mal gucken, ob ich das finde, alles, was wir hier sehen, ist im Grunde genommen Bestandteil des Archivs von GTA. Und innerhalb dieses Archivs gibt es Möglichkeiten, wie zum Beispiel, ich muss, ich muss das abschalten, ich muss gucken, tut mir leid. Ich weiß nur nicht, wie ich hier rauskommen kann aus dem, aus der Präsentation. Das geht nämlich nicht gerade Sekunde. So, jetzt kann ich es machen. Ne, kann ich nicht machen. Egal. Ja, wie man sieht, es gibt ein Issue Tracker. Es gibt die Möglichkeit, ein Wiki einzubinden. Es gibt ein Aktivitäten-Tracker. Es gibt ein entsprechendes Code-Ansicht. Es gibt die Möglichkeit, hier sich Code-Hide Lightning, ein Editor reinzumachen, Änderungen direkt online zu committen, beziehungsweise die Möglichkeit zum Beispiel Pool-Request. Das sind Requests von anderen Usern, die gerne Änderungen drin haben zu verwalten und so weiter und sofort. Wenn man reinkommt, ich muss jetzt wieder umschalten, tut mir echt leid. Es ist nicht zu fassen. Tut mir leid, mein Bildschirm will gerade nicht. So, sich wieder umgestellt. Jut, diese Einstellung beibehalten. So, kommen wir mal weiter. Ich werde jetzt mal beispielsweise an meinem Rechner mal GTA installieren. Es gibt natürlich die Möglichkeit, GTA auch zu installieren über Docker-Container. Ich persönlich habe etwas dagegen, mit Docker oder Snap zu arbeiten, zumindest wenn es sich um Systemdienste handelt. Da möchte ich die selber mehr oder weniger verwalten. Die Schritte sind relativ einfach. Und zwar als erstes muss man GTA runterladen. Das macht man, wie gesagt, als ein einziges Archiv. Ich mache das jetzt in Local Bin. Man sieht bereits, es existiert GTA und das ist auch ausführbar. Dann muss man ein Benutzer hinzufügen. Das ist einfach der Benutzer-Git. Der wird das System Benutzer angelegt und bekommt Home-Git als Ort, wo dann auch die Repositives liegen. Das kann man sich natürlich selber machen. Was ganz wichtig ist, ein paar Verzeichnisse machen, ist auch in der Dokumentation, ist es ganz gut beschrieben. Im Grunde genommen sind es zwei Verzeichnisse. Einmal Lib-Verzeichnissen, wo die temporären Dateien gespeichert werden oder die variablen Dateien gespeichert werden und ein Verzeichnis in ETC, wo das Programm dann selber die Konfigurationsdatei schreibt. Die Konfigurationsdatei ist eine App inny. Normalerweise ist es so, dass man sich da ein Service anlegt. Das wird auch beschrieben, wo das ist und wie das zu machen ist. Es ist relativ einfach. Ich will, weil das jetzt hier auf meinem Laptop ist, Githair einfach mal lokal starten. So, jetzt ist quasi der Server gestartet. Das ist eine etwas kritische Situation, weil da im Grunde genommen jetzt das System offen ist. Das heißt, das was ich jetzt gerade gemacht habe, ich habe Githair quasi runtergeladen, ausführbar gemacht, die entsprechenden Ordner angelegt und kann das jetzt hier verwalten. Das heißt, ich gehe jetzt hier auf Anmelden und bekomme so eine Erstkonfiguration. Das heißt, ich kann meine SQL-Daten angeben, ich kann die Authentifizierung eingeben. Ich habe verschiedene Administratoreinstellungen. Githair übernimmt für mich. Deshalb finde ich das unter anderem auch so genial. Zum Beispiel auch Geschichten wie die Anmeldung bei Let's Encrypt, wenn man sein Githair direkt irgendwie mit HTTPS absichern will. Githair selber bietet verschiedene, ich gehe mal eben auf die Einstellungen, verschiedene Möglichkeiten der Sicherheit. Das heißt, ich habe die Möglichkeit, O-Out zu nehmen, ich habe die Möglichkeit, LDAP zu nehmen. Deshalb benutzen wir bei der C-Base unter Code C-Base.org auch ein Githair. Ich habe die Möglichkeit, wie gesagt, meine Deploy-Schlüssel zu hinterlegen, damit ich einfach mit dem Repositie arbeiten kann. Und was zumindest für Githair auch noch spricht, ist eine relativ umfangreiche App, mit der ich mir selber Programme schreiben kann, mit der ich zum Beispiel meine Reposities dann nochmal verwalte, teste, irgendwelche Grundjobs ausführe und so weiter und so fort. Zusätzlich gibt es noch Schnittstellen, Möglichkeiten, so Webhooks für Dienste, die bereits fertig eingerichtet sind, nämlich für Slack oder für MS Teams, Discord, Telegram, da könnte ich mir dann direkt in die Telegram Channel irgendwelche Issue, Meldungen oder Pull Request oder so was reingeben. Vielleicht schauen wir uns nochmal eben kurz den Featurevergleich an, weil ich sehe, ich habe noch ein bisschen Zeit. Githair ist zumindest, was die Open Source Alternativen angeht, sehr komplex und hat fast alle Möglichkeiten, die die großen Alternativen auch hat. Also von meiner Seite aus spricht nichts dagegen, dass man das nicht auch in einer großen Organisation, in einer großen Firma, mit großen Teams und so weiter laufen lassen kann. Witzigerweise ist der Githair-Source selber auf GitHub gehostet. Ich weiß nicht, warum. Wahrscheinlich, weil die Mehrheit der Entwickler Open Source immer noch unter GitHub macht. So, dann kommen wir zur Installation. Die hatten wir schon, genau. Ja, vielleicht noch etwas zum Abschluss. Wichtig ist natürlich die Sicherheit von Githair. Githair erstellt, wie gesagt, bei der Erstkonfiguration über das Web-Interface eine App-Inni. Die kann ich natürlich auch händisch erstellen. Die muss ich nicht von Githair erstellen lassen, aber das macht es halt, wenn die nicht existiert. Die kann auch sehr umfangreich aufsführen, je nachdem, welche Option man dafür benutzt. Die App-Inni sollte man nach der Einrichtung sperren für Githair, ganz einfach, um auf Nummer sicher zu gehen. Gut, wie gesagt, Let's Encrypt ist auch wichtig. Pull und Push kann über HTTPS und SSH erfolgen. Am Grunde genommen habe ich keine großen Unterschiede zu GitHub gefunden. Ja, damit bin ich, glaube ich, fertig und auch in der Zeit. Ist das richtig? Ja, gut in der Zeit. Ich glaube... Ja, ich danke dir Rubel.