 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 Gitrepositis. Dazu kommen wir später. Ich will so eine Einführung machen, ganz kurz in Git, weil ich weiß, dass zwar fast jeder Git kennt, aber es gibt immer wieder Leute, die das nicht benutzen und stattdessen weiß ich nicht, mit irgendwelchen USB-Sticks arbeiten. Git ist eine Versionsverwaltung, ähnlich Subversion, Bitkeeper und anderen Versionsverwaltungen, die halt acht gibt auf den Sourcecode, auf die Projekte. Git 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. Git basiert vor allen Dingen darauf, dass man mit einem Server arbeitet, wo die Repositis liegen und dass man verteilt arbeiten kann. Das heißt, es gibt halt Leute oder Teams können entsprechend Commits machen und ja, so weit ist es bekannt. Vielleicht kurz zu den Vorteilen von Git gegenüber anderen Versionsverwaltungen. Es ist relativ stabil, es ist sicher und vor allen Dingen sehr effizient. Git 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 eine Repositie erstellen und das dann auch bedienen, weil es gibt nur eine Handvoll Befehle. Das eine ist der Innetbefehl, ist klar, erstelle Repositie dann oder die meisten werden es so machen, die werden sich einen Repositie runterladen erst mal, was bereits im Netz existiert und dann damit arbeiten, dann gibt es Ad, Dateien hinzufügen, Commits, Senden, Push, also nicht Commits, 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 ihr eigentlich sehr einfach und die macht deutlich, dass man dann nicht studieren muss. Vielleicht noch mal was zum Thema Best Praxis 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 weiß 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 GT ja noch zu. Man sollte Branches sinnvoll einsetzen, vielleicht ein Beispiel, also Branches sind quasi Verzweigung, Kopien, die weiter entwickelt werden können, parallel zu einem Hauptstrang. Meistens wird es so benutzt, dass man halt ein Stable Release hat und ein Entwicklungsrelease und dann irgendwann sagt, okay, wir fressen das jetzt und packen es zurück in das Stable Release. Ich mache das unter anderem so, dass wir All-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, weiß ich nicht, 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 GT ja sehr gut. Ja, so andere Sachen. Es gibt immer ganz viele Tipps dazu. Einige Leute sagen nicht, 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 GT ja 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 Git her. 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 da drauf. Gox ist wie GTR auch in Go geschrieben. GTR 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 kurz gucken, wie viel Zeit ich habe. Das geht aber gut. Vielleicht Grundsätzliches. GitR 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 Fontools und Libraries installieren. Das ist nicht jedermanns Sache. 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 OpenSSR und natürlich eine SQL-Datenbank, MySQL oder Postgres SQL. GitEA 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 ... Ja, das Problem ist, ich sehe ... Also, das ist mein privates Git Repository. Ich habe da viele oder mein privates GitEA, was ich eingerichtet habe. Ich habe da auch einige Open-Source-Repositives, die das GitEA selber ist relativ moderat, was so die Hardware-Anforderungen angeht und läuft halt so mit einer Web-Oberfläche. Der Vorteil von GitEA ist, es kommt als ein Archiv. Das heißt, alles, was wir hier sehen, die ... Ich gehe mal auf ein Open-Source. Mal gucken, ob ich das finde. Alles, was wir hier sehen, ist im Grunde genommen Bestandteil des Archivs von GitEA. Und innerhalb dieses Archivs gibt es Möglichkeiten, wie zum Beispiel ... Ich muss das abschalten. Ich muss gucken, tut mir leid. Ich weiß nur nicht, wie ich hier rauskommen kann aus der Präsentation. Das geht nämlich nicht gerade. Sekunde. So, jetzt kann ich es machen. Nee, 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 kommen, bzw. die Möglichkeit zum Beispiel Pool-Request. Das sind Requests von anderen Usern, die gerne Änderungen drin haben zu verwalten und so weiter und so fort. Wenn man reinkommt, ich muss jetzt wieder umschalten, tut mir echt leid. Das 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 beispielshaft an meinem Rechner mal GTA installieren. Es gibt natürlich die Möglichkeit, GTA auch zu installieren über Docker-Container. Ich persönlich habe was 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 einen Benutzer hinzufügen. Das ist einfach der Benutzer-Git, der wird das System Benutzer angelegt und bekommt halt Home-Git als Ort, wo dann auch die Reprosities liegen. Das kann man sich natürlich selber machen. Was ganz wichtig ist, ist ein paar Verzeichnisse machen. Ist auch in der Dokumentation, ist es ganz gut beschrieben. Im Grunde genommen sind es zwei Verzeichnisse, einmal ein Lib-Verzeichnis, 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, ist relativ einfach. Ich will, weil das jetzt hier auf meinem Laptop ist, GTA einfach mal lokal starten. 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 GTA 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. GTA ü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 GTA direkt irgendwie mit HTTPS absichern will. GTA 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 GTA. Ich habe die Möglichkeit, wie gesagt, meine Deploy-Schlüssel zu hinterlegen, damit ich einfach mit dem Repositiv arbeiten kann. Und was zumindest für GTA auch noch sprecht, ist eine relativ umfangreiche API, mit der ich mir selber Programme schreiben kann, mit der ich zum Beispiel meine Repositives dann nochmal verwalte, teste irgendwelche Cronjobs ausführe und so weiter und sofort. 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 sowas reingeben. Vielleicht schauen wir uns noch mal eben kurz den Feature-Vergleich an, weil ich sehe, ich habe noch ein bisschen Zeit. GTA 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 ausspricht 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 GTA 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 GTA. GTA 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 GTA erstellen lassen, aber das macht es halt, wenn die nicht existiert. Die kann auch sehr umfangreich aufs führen, je nachdem, welche Option man dafür benutzt. Die App-Inni sollte man nach der Einrichtung sperren für GTA, 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. Im 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...