Hallo zusammen

Zur einfacheren Zusammenarbeit und damit ihr eine Versionskontrolle für euren Code habt, sollt ihr in Middleware Git verwenden

Falls du noch keine Erfahrung mit Git hast, sprechen wir in diesem Video über die grundlegenden Konzepte und einige komplexere Sachen wie Branches und das Auflösen von Konflikten

Warum sollte man eigentlich Git in einem Softwareprojekt verwenden?

Git ist ein Versionskontrollsystem, also ein System, das eure Änderungen an Dateien erfasst und mit einem Zeitstempel speichert

es gibt dabei normalerweise einen zentralen Ort, an dem der gemeinsame Stand des Repos gespeichert wird, in eurem Fall Gitlab

von hier kann sich jeder Entwickler des Projekts eine lokale Kopie ziehen und an dieser arbeiten

über das zentrale Repo kann dann jeder von euch seine Änderungen den anderen Gruppenmitgliedern zur Verfügung stellen

eine gemeinsame Arbeit an einem Projekt ist dadurch relativ einfach

Wenn ihr gleichzeitig an unterschiedlichen Stellen im selben Projekt arbeitet, kann Git diese Änderung meist einfach von alleine zusammenführen

ihr müsst dann nicht die Dateien händisch mergen.

Wenn es doch zu Konflikten kommt, die Git nicht alleine auflösen kann, wird euch das aber angezeigt und ihr könnt den Konflikt einfach erkennen und selbständig lösen

auch ist die parallele Entwicklung mehrerer Features mittels Branches ist ein großer Vorteil von Versionskontrollsystemen wie Git

Zusätzlich kann man leicht durch die alten Versionen von seinem Code springen. Wenn plötzlich ein neuer Fehler im Programm auftaucht

kann man so z.B. die alten Version durchsuchen um die Änderung zu finden, die den Bug am Ende verursacht hat

Es gibt neben Git natürlich noch andere Versionskontrollsysteme. Git ist allerdings sehr weit verbreitet und es gibt einige öffentliche Hosting-Plattformen wie z.B. GitHub

Hier in Middleware verwenden wir das von den CIP-Admins gehostete Gitlab der Informatik der FAU

So. Kommen wir nun zur grundlegenden Bedienung von Git

Hier seht ihr einen typischen Git-Arbeitsablauf, durch den wir uns jetzt Stück für Stück durchhangeln

Wenn man in einem entfernten Repository arbeiten möchte, braucht man zuerst eine lokale Kopie auf dem eigenen Rechner

diese holt man sich mittels git clone, um das entfernte Repository zu klonen braucht git clone als Parameter die URL des Repositories

im Gitlab findest du das auf der jeweiligen Projektübersichtsseite

das Muster, welches wir in Middleware verwenden, ist immer i4-exercises, mw für Middlware, das derzeitige Semester in Kurzform, sowie middleware-gruppe-eure Gruppennummer

am einfachsten ist es, das Git mit SSH zu klonen. Dafür musst du einen SSH-Schlüssel im Gitlab hinterlegen

Wie man das macht, erklären wir ein Video zum Organisatorischen. Oder du schaust dir einfach die Anleitungen im Gitlab selbst an

Wenn ihr euer Repository klont, wird am aktuellen Ort ein Ordner für das Repository erstellt und alle vorhanden Dateien dorthin geladen

hier im Beispiel sieht man, dass das Repo bereits eine README.md enthält. Man kann jetzt direkt mit der Arbeit beginnen

Natürlich möchte man die getane Arbeit auch irgendwann wieder zurück ins zentrale Repo legen. Die Schritte dafür schauen wir uns jetzt an

davor aber noch ganz kurz zu den unterschiedlichen Stufen von Git in eurer lokalen Kopie

In eurem Git-Ordner gibt es nämlich drei verschiedene Bereiche: Euren Workspace, den Staging-Bereich und das lokale Repository selbst

um sich den Unterschied zwischen Workspace, Staging-Bereich und Repo besser vorstellen zu können, gibt es eine ganz nette Analogie

stell dir einen Schreibtisch mit lauter Zeug drauf vor, an dem Zeug arbeitest du gerade, das ist dein Workspace

auf dem Schreibtisch ist zudem eine Box, wenn du mit etwas fertig bist, packst du es in die Box

du kannst jederzeit Zeug aus der Box rausnehmen oder reinlegen, das ist der Staging-Bereich

etwas aus dem Staging-Bereich ins Repository zu committen ist jetzt, wie wenn man die Box zu klebt und ein, am besten möglichst aussagekräftiges Label, drauf packt

die Box ist jetzt eine zusammenhängende Einheit, also ein Commit

um Änderungen zwischen den verschiedenen Bereichen in eurem Git hin und her zu schieben, gibt es natürlich unterschiedliche Befehle

Zuerst: Um Sachen von einem Workspace in die Staging-Area zu legen, also in die Box zu packen, verwendet man git add

wenn man Dateien in den Staging-Bereich legt, wird der aktuelle Zustand der Datei hinzugefügt

die Änderungen selbst sind jetzt aber noch nicht im Repository wirksam, das passiert erst mit dem nächsten Commit

Aber sonst noch ein ganz hilfreicher Tipp: Wenn man einen Befehl nicht auf alle Änderungen einer Datei, sondern nur einen Teil davon ausführen möchte

kann man das mit dem Parameter -p machen, -p lässt dich einzelne Änderungen auswählen

Klassisches Beispiel: Du hast noch Debug-Ausgaben in deinem Code, die du aber nicht committen willst. Mittels -p kannst du dann nur die Änderung auswählen, die wirklich wichtig sind

diesen Parameter gibt es für fast alle Befehle. Ich verwende ihn eigentlich sehr gerne, da man die Änderung auch direkt noch mal sieht bevor man sie hinzufügt oder entfernt

Um Änderungen zum Staging-Bereich hinzuzufügen, verwendest du das schon erwähnte git add

Wenn du eine Datei in deinem Repo löscht, musst du das Git aber auch noch mal extra mitteilen. Das macht man mittels git rm

Falls man aus Versehen zu viel in den Staging-Bereich gepackt hat und Änderung wieder daraus entfernen möchte, kann man git reset head verwenden

auch hier bietet sich wieder -p als Parameter an

die Änderungen bleiben natürlich in Workspace bestehen, sie werden nur nicht mehr als geaddet markiert

Falls man tatsächlich mal Änderungen wegwerfen will, geht das mit git checkout --