Sehr gut, damit sollten wir aufgezeichnet werden. Okay, nochmal für die Aufzeichnung. Hallo, willkommen zur Vorlesung IBGS.

Ich bin nicht Michael Kohlhase, der sitzt in einem Meeting Fest und deswegen halte ich heute die Vorlesung.

Wir würden dann mit der Wiederholung anfangen. Ich hoffe, ihr könnt alle meine Slides sehen, auch wenn ich sie in den Präsentationsmodus schiebe.

Kann mal irgendjemand signalisieren, ob die gut sichtbar sind?

Ja, wunderbar. Dann machen wir das so.

Ihr habt in den letzten Vorlesungen euch mit Versionskontrolle beschäftigt und insbesondere habt ihr das Versionskontrollsystem Git vorgestellt bekommen.

Git wurde in den 90ern, glaube ich, irgendwann mal von Linus Torvalds entwickelt. Das ist auch der Mensch, der hinter dem Linux Kernel sitzt.

Es geht dabei darum, dass wir lokale Repositorien oder Repositories haben und in denen lokal arbeiten können und dann diese Änderungen, die wir durchgeführt haben, in andere Repositories im Internet oder auf der gleichen Maschine oder auf irgendeiner Maschine, mit der wir andersweitig verbunden sind, verbreiten können.

Genau. Ich glaube, die wichtigsten Grundlagen von Git hatten wir schon auch in der Vorlesung davor schon kurz besprochen.

Deswegen halte ich mich hier nicht zu lange auf. Wir haben darüber geredet, wie ihr Git installieren könnt und wie ihr ein Repository initialist, entweder über GitHub oder GitLab.

Das sind Anbieter. GitLab ist Open Source, GitHub ist von Microsoft dieser Tage und dann könnt ihr dort entweder ein Projekt anlegen und es direkt klonen oder ihr könnt auch jeden beliebigen Ordner auf eurem Rechner zu einem Git Repository machen, in dem ihr sowas wie Gitinit eingibt in eure Shell.

Dann habt ihr auch da schon ein Repository ganz ohne einen dieser Anbieter. Ein Repository kann zu einem Remote Repository connected werden über den Git Remote Befehl.

Das ist meistens, wenn ihr einfach in GitLab oder in GitHub ein Repository anlegt und dann einfach klont, ist es schon entsprechend connected. Da müsst ihr es nicht mehr von Hand machen. Aber wenn ihr jetzt irgendeinen Ordner in eurem System zu einem Git Repository machen wollt, dann müsstet ihr, bevor ihr irgendwo hin pushen könnt, müsstet ihr noch ansagen, wohin denn bitte gepusht werden soll.

Ihr müsst dann dem Repository erst noch erzählen, wohin die Änderungen geschickt werden sollen.

Das ist allerdings meistens eine Sache, die ihr nicht von Hand in der Shell machen müsst. In den allermeisten Fällen wird es so sein, dass ihr ein bestehendes Repository entweder in ein Projekt einsteigt, das schon unterwegs ist und dann einfach ein bestehendes Repository klont oder dass ihr euch ein frisches Repository anlegt und dann das klont.

Dann müsst ihr diesen Teil nicht mehr von Hand machen, der ist dann schon für euch erledigt.

Genau. Wir haben in einem Git Repository gibt es immer diesen versteckten Ordnerpunkt Git. Da wird alles Mögliche drin gehalten, was irgendwie sich Git merken muss. Zum Beispiel wenn ihr einen Pull durchgeführt habt oder einen Fetch in diesem Fall.

Und schon Änderungen von einem Remote Repository auf eurem Rechner runtergeladen habt, aber die noch nicht mit den Änderungen, die ihr lokal gemacht habt, gemerscht haben wollt, dann liegt sowas im Git Directory.

Da liegt auch die ganze History drin, dass man immer wieder darauf zurückgreifen kann. Ja, okay, aber das hier ist Mox. Ich möchte gerne auf den Stand zurück, der vor fünf Stunden war oder ich möchte spezifisch zu diesem Commit zurück.

Da war noch alles in Ordnung. Diese History und alles Mögliche liegt im Git Directory. Und da müsst ihr euch in der Regel auch nicht persönlich darum kümmern, das ist alles, was Git das Programm für euch macht.

Die Basic Commands sind Git Clone, um irgendeinem Repository auf eurem Rechner zu klonen. Git Add fügt eine Datei, wie man so schön sagt.

Das heißt, hallo, ich habe Änderungen in dieser Datei und ich möchte gerne, dass wir diese Datei in Zukunft betrachten als eine Datei, die relevant ist, die wir gerne mit an der wir arbeiten. Wir kündigen damit an, wir arbeiten an dieser Datei und wir wollen diese Datei Versions tracken.

Insbesondere könntet ihr auch sagen, okay, ich habe jetzt Änderungen an dieser Datei und an dieser Datei gemacht, meinetwegen an Datei A und Datei B, aber ich möchte erst mal nur die Änderungen an Datei A veröffentlichen.

Dann würdet ihr Git Add A machen, aber nicht Git Add B und dann könnt ihr in eurem Commit, das ist das nächste, eine Sammlung von Änderungen, könnt ihr dann die eine Datei einfügen und die andere nicht rauslassen.

Ein Commit ist einfach nur ein Statement von, okay, wir sind an einem Punkt, wo ich irgendwie ein paar Änderungen sinnig zusammenfügen kann und dann könnt ihr mit Git Commit minus M und dann irgendeine hoffentlich sinnigen Commit Message zusammenfassen und diese Commits könnt ihr dann später veröffentlichen.

Zwischendrin ist es immer ganz hilfreich, irgendwie einen Auge auf Git Status zu haben und da wird euch gesagt, wie der aktuelle Stand von dem Repository ist, ob es irgendwelche Probleme gibt, welche Dateien geadded wurden, wie viele Commits ihr vor- oder nach-Master seid, alles so was.

Genau. Dann haben wir hier ein Example Workflow, über den gehe ich jetzt nicht noch im Spezifischen nochmal drüber. In Gits gibt es dann auch noch so was wie Branches, das sind dann, wir haben irgendjemanden im Chat, gibt es eine Frage.

In Zweifelswahl einfach reinrufen oder kann die mal jemand vorlesen, in Screenshare ist es irgendwie nicht möglich Chat zu lesen.

Ne, ich wollte nur begrüßen. Also hallo.

Okay.

Danke.

Hallo.

Genau. Du bist rechtzeitig gekommen zur kurzen Wiederholung von Git und allem was dazugehört.

Wir waren dabei, dass wir Branches vorgestellt haben. Die Idee ist, dass wir sozusagen kleine Abzweigungen von dem Hauptzustand des Repositories in einen Branch geben können.

Zum Beispiel, wenn Michael und ich jetzt an einem Projekt zusammenarbeiten und Michael arbeitet die ganzen Fehler raus, die ich reingearbeitet habe, oder ich möchte gleichzeitig während er das macht irgendwie ein neues Feature einfügen, dann würde ich meistens einen Branch machen, sodass wir uns da nicht in die Quere kommen.

Das heißt, wir können dann erst mal parallel weiterarbeiten und dann später irgendwann die Änderungen vom einen Branch in den anderen übertragen.

Genau.

Das gleiche.

Genau. Git alleine, das Kommando-Zeichenprogramm alleine reicht, um alles dies irgendwie zu tun.

Meistens haben wir aber halt entweder GitLab oder GitHub, das sind diese Repository-Manager, dann haben wir halt eine Web-App drum herum, die es uns einfacher macht, irgendwie das Ganze anzulegen und die richtigen Befehle zu finden und User-Management zu machen.

Das könnten wir alles auch absolut über die Kommando-Zeile machen, aber mit so einer Web-App drum herum ist es in der Regel einfach hübscher.

Genau.

Es wurde auch darüber geredet, dass man statt sich immer mit dem Username und Passwort bei unserem GitLab anzumelden, es auch möglich ist, das mit SSH zu machen.

Dafür müsste man sich einen SSH-Key anlegen und dann wurde noch ein bisschen über Kryptographie geredet, was so ein SSH-Key eigentlich genau ist und was man dafür braucht und wie das funktioniert.

Über die Details würde ich jetzt hier nicht nochmal rüber gehen, es sei denn, es ist irgendwie super wichtig oder es gibt noch eine Frage dazu.

Die Idee ist, dass es jeweils einen privaten und einen öffentlichen Key gibt, den privaten Key, den hält man für sich, deswegen heißt er auch Secret Key und den öffentlichen Key kann man veröffentlichen, deswegen heißt er so.

Die Idee ist dann, dass andere Leute eine Nachricht an mich verschlüsseln können, ohne dass sie meinen privaten Key kennen und nur die Person, die den privaten Key hat, kann dann hinterher diese Sache auch wieder entschlüsseln.

Und jetzt kann man das so machen, dass man einfach sagt, ok, ich möchte bitte nicht jedes Mal mein Passwort angeben, dann kann ich den SSH-Key hier hochladen und dann werde ich darüber authentifiziert.

Das ist aber optional, das ist nicht zwingend.

Ich persönlich habe für die Leute aus meinem Tutorial wissen, dass ich benutze momentan auch noch keinen SSH-Key mit diesem GitLab, für Arbeitsprojekte benutze ich einen, weil man da schon sehr häufig irgendwie Dinge eingibt, das ist aber wie gesagt optional.