So, Zeit für iWGS. Wir sind heute noch immer an Git beschäftigt und GitLab.

Ich hoffe, Sie haben mal ein bisschen mit dem Zeugs rumgespielt.

Wir haben eine einfache Möglichkeit hingegeben, das zu tun.

Die Übungen sind immer noch schlecht besucht.

Wir können da leider nichts für.

Also unsere Totoren waren auch nur semi glücklich.

Gott sei Dank haben wir einen Frühaufsteher und einen Spätaufsteher.

Sie haben das schon unter sich so ausgemacht, dass es sozial verträglich war.

Aber wir scheinen relativ stark am Ende der Nahrungskette zu stehen, was Zeiten angeht.

Das ist meine Verschwörungstheorie.

Wir haben nichts gegen gute Zeiten.

Vielleicht können Sie mit der Gnade mitwirken.

Ich glaube, dass auch Philipp und Jonas bereit wären, wenn es einen Raum gibt, die Zeiten zu ändern.

Wir haben ja nichts außer...

Genau. Wir haben jedenfalls keine anderen Räume gekriegt.

Wir gucken uns Source Code Management und Project Management Systeme an.

Das sind Systeme, die nicht entstanden sind, weil sie so viel Spaß machen,

sondern weil sie absolut notwendig sind, wenn man Projekte hat, die nicht trivial groß sind und nicht trivial lange laufen.

Eigentlich für Ihre Hausaufgabenprojekte, das ist nicht die Sache.

Aber immer, wenn es länger wird und mehr Leute involviert,

braucht man Unterstützung, gemeinsam kollaborativ an Dingen zu arbeiten, weil man nicht immer in einem Raum sitzen kann.

Die Idee dabei ist ganz einfach. Wir haben uns das angeguckt.

Wenn man an einem Satzdateien arbeitet, dann kann man sehr viel erreichen, indem man nur noch auf einer Kopie arbeitet.

Wenn das Original woanders ist, hat man viele Vorteile.

Das erste ist, andere können auch auf das Original zugreifen, ohne sie zu stören.

Und wenn das Original an einem sicheren Ort ist, kann ihr Laptop passieren, was ihr möchte.

Das ist im Wesentlichen die Idee hier.

Wir teilen eine Datei auf in einer Repository Kopie und in einer Arbeitskopie.

Wir arbeiten auf der Arbeitskopie und das Repository macht das Bookkeeping über die gesamte Zusammenarbeit.

Der Workflow ist ganz einfach.

Wenn man eine Arbeitskopie hat, macht man darauf ein Checkout oder wie wir das hinterher in Git nennen werden, ein Clone.

Und wenn man Änderungen gemacht hat, bringt man die mit einem Commit ins Repository zurück.

Wenn man schon eine Kopie hat, aber die nicht mehr synchronisiert ist mit der Repository Version, muss man ein Update machen.

Und wenn man schon nicht nur eine Kopie hat, sondern auch schon Änderungen gemacht, muss man das durch ein Merge machen.

Weil im Merge können Merge-Komplikte auftreten, die muss man irgendwie handeln.

Da kann das System einem nicht helfen.

Wenn also zwei verschiedene Leute an verschiedenen Kopien derselben Zeile gearbeitet haben, dann weiß Git nicht, was es damit machen soll.

Kann es auch nicht wissen, weil es ja nicht weiß, was ihre Intentionen waren mit dieser einen Zeile.

Deswegen sagt Git, das ist was die anderen gemacht haben, das ist was du gemacht hast, tu was damit.

Und dann tut man damit was und kann dann wieder ein Commit machen.

Das ist der Basis Workflow in Repository-Systemen.

Und der hat viele Vorteile.

Wir haben heute einen Merge-Komplikt ausprobiert am Dienstag und haben dann festgestellt, dass wenn man das händisch macht, also dann ein Merge macht, dann ist es ziemlich schwer, der Manuel noch irgendwas rauszufinden.

Also was ist die Änderung? Kann man da in der Vorlesung den Nimm-Ein-Maiorand-Bus vorstellen?

Ich nehme an, sie beziehen sich auf, dass das Zeug so aussieht.

Und dann kommt hier irgendwas, was man nicht lesen kann.

Dann kommt die eine Version, dann kommt meistens sowas von der Bauart.

Und dann kommt die andere Version und dann gibt es typischerweise sowas von der Bauart, möglicherweise mit mehr Kuddel-Muddel.

Wenn diese Dinger nicht zu groß sind, ist es nicht so schlimm.

Wenn die groß sind, ist es tatsächlich gut, wenn es dann Tools gibt.