WEBVTT

00:00.000 --> 00:10.760
Der primäre Zweck einer Versionsverwaltung ist das Archivieren von Dateien.

00:10.760 --> 00:17.200
Dadurch ist es möglich, die Versionsgeschichte, also wer was wann geändert hat, nachzuvollziehen

00:17.200 --> 00:20.080
und bei Bedarf auch alte Versionen wiederherzustellen.

00:20.080 --> 00:24.880
Im Bereich der Softwareentwicklung ist das keineswegs eine Neuerfindung, sondern wird

00:24.880 --> 00:27.040
schon seit einem halben Jahrhundert eingesetzt.

00:27.040 --> 00:33.000
Das 1972 von Bell Labs entwickelte Source Code Control System war das erste wirklich

00:33.000 --> 00:35.000
relevante Versionsverwaltungssystem.

00:35.000 --> 00:40.400
Da zu dieser Zeit Speicherplatz noch etwas kostbar war, hat es die erste Version und

00:40.400 --> 00:45.080
darauf aufbauend nur die Änderungen gespeichert, und zwar in einem versteckten Unterordner.

00:45.080 --> 00:50.360
Wenn nun aber die Versionsgeschichte länger wird, also viele Änderungen dazukommen, dann

00:50.360 --> 00:55.200
kann das Durcharbeiten schon seine Zeit dauern, insbesondere da meist nur die neuesten Versionen

00:55.200 --> 00:56.200
die interessant sind.

00:56.200 --> 01:02.680
Jürgen Kleinüter hat da mit unserer DNS-Verwaltung an der Uni auch das passende Beispiel, weshalb

01:02.680 --> 01:06.520
mit der Zeit auf das Revision Control System umgestellt wurde.

01:06.520 --> 01:11.320
Dieses war zwar etwas einfacher gestrickt, hatte zum Beispiel keine Prüfsumme mehr,

01:11.320 --> 01:15.960
speicherte aber vor allem nur die letzte Version und delt das zu den vorherigen Änderungen

01:15.960 --> 01:17.760
und war damit deutlich performanter.

01:17.760 --> 01:24.880
Und ja, RCS wird bei uns an bestimmten Orten immer noch verwendet, insbesondere um lokale

01:24.880 --> 01:27.600
Dateien, vor allem Konfigurationsdateien zu tracken.

01:27.600 --> 01:33.440
Aber schon in den 80ern kam die Anforderung, Dateien nicht nur lokal, sondern projektbezogen

01:33.440 --> 01:38.160
über Netzwerk zu versionieren, was die Weiterentwicklung zum Concurrent-Version-System begründete.

01:38.160 --> 01:43.560
Dort konnten an einer zentralen Stelle im Netzwerk mehrere Dateien gespeichert werden,

01:43.560 --> 01:46.920
allerdings waren Revisionen weiterhin nur auf einzelne Dateien bezogen.

01:46.920 --> 01:52.360
Dieses System erfreute sich insbesondere in der aufkommenden OMSource-Bewegung großer

01:52.360 --> 01:57.000
Beliebtheit, wurde aber nach und nach von dem um die Jahrtausendwende entwickelten Subversion

01:57.000 --> 02:02.320
abgelöst, welches zwar das Konzept einer zentralen Stelle adaptierte, nun aber gemeinsame

02:02.320 --> 02:07.400
Revisionen für mehrere Dateien einführte und im Gegensatz zu den Vorgängen auch beim

02:07.400 --> 02:10.960
Umbenennen und Verschieben von Dateien die Versionsgeschichte beibehielt.

02:10.960 --> 02:17.840
Im Jahr zuvor wurde jedoch mit dem ursprünglich proprietären Bitkeeper das erste bedeutende

02:17.840 --> 02:20.480
verteilte Versionsverwaltungssystem veröffentlicht.

02:20.480 --> 02:26.480
Das Konzept war nun für freie Software relativ interessant, weil man sehr einfach Forks erstellen

02:26.480 --> 02:30.280
und die Entwicklung eines Projektes in unterschiedliche Richtungen vorantreiben konnte.

02:30.280 --> 02:35.080
Die dahinterstehende Firma Bitmover hat das auch erkannt, um mittels einer umstrittenen

02:35.080 --> 02:39.840
Lizenz OMSource-Projekten die kostenlose Nutzung erlaubt, jedoch unter der Bedingung,

02:39.840 --> 02:43.880
sich einige Zeit nicht an der Entwicklung konkurrierender Versionsverwaltungssysteme

02:43.880 --> 02:44.880
zu beteiligen.

02:44.880 --> 02:50.960
Aber natürlich dauerte es nicht lang, bis mit Source Puller eine kompatible OMSource-Alternative

02:50.960 --> 02:56.560
begonnen wurde, was dann schlussendlich dazu führte, dass 2005 alle kostenlosen Lizenzen

02:56.560 --> 03:00.120
beendet wurden und viele OMSource-Projekte nun ein Problem hatten.

03:00.120 --> 03:06.800
Das traf auch Linux, das seit 2002 auf Bitkeeper aufgesetzt hatte, nach 10 Jahren komplett

03:06.800 --> 03:08.280
ohne Versionsverwaltungssystem.

03:08.280 --> 03:14.840
Obwohl zu dieser Zeit unter anderem mit Mercurial und Basar auch weitere frei verteilte Versionsverwaltungssysteme

03:14.840 --> 03:20.400
das Licht der Welt erblickten, hat Linus Torvalds höchstpersönlich im April 2005

03:20.400 --> 03:22.680
mit Git ein eigenes freies Tool begonnen.

03:22.680 --> 03:27.400
Für die erste Version brauchte er nur ein paar Tage und bereits nach drei Monaten wurde

03:27.400 --> 03:29.520
der komplette Linux-Kernel damit verwaltet.

03:29.520 --> 03:34.240
Und da Git auch sehr gut auf unsere Bedürfnisse zugeschnitten ist, wollen wir es auch für

03:34.240 --> 03:35.240
die Übung verwenden.

03:35.240 --> 03:41.240
Die Hauptmerkmale von Git sind unter anderem die nicht-lineare Entwicklung mittels verschiedener

03:41.240 --> 03:46.240
Zweige, welche normalerweise für einzelne neue Features verwendet werden, sowie die

03:46.240 --> 03:51.760
kryptographische Sicherheit des kompletten Versionsverlaufs durch einen auf SHA-1 Prüf-Sommen

03:51.760 --> 03:53.040
basierenden Hash-Bombs.

03:53.040 --> 03:58.760
Die Dateien eines Verzeichnisses werden dabei als Teilpakete in komprimierter Form in einem

03:58.760 --> 04:00.760
versteckten Unterordner gespeichert.

04:00.760 --> 04:05.720
Dabei wird die Entwicklung mit einem oder auch mehreren entfernten Repos unterstützt,

04:05.720 --> 04:10.200
aber nötig sind diese nicht, es kann auch komplett lokal gearbeitet werden.

04:10.200 --> 04:13.880
Das will ich auch an einem einfachen praktischen Beispiel demonstrieren.

04:13.880 --> 04:19.640
Ich erstelle über die Kommandozeile einen Ordnerbeispiel meinem Workspace.

04:19.640 --> 04:25.440
Mittels git init kann ich darin ein Git Repository initialisieren, das liegt dann im Unterordner

04:25.440 --> 04:26.440
.git.

04:26.440 --> 04:32.880
Ich lege eine leere Datei namens readme.md an und kann dann diese mittels git add hinzufügen

04:32.880 --> 04:38.400
und damit in den Staging-Bereich, auch Index genannt, kopieren, einer Sammelstelle, welche

04:38.400 --> 04:40.480
den nachfolgenden Commit vorbereitet.

04:40.480 --> 04:46.960
Wenn ich diesen mittels git Commit dann ausführe, werde ich aufgefordert, eine Nachricht einzugeben,

04:46.960 --> 04:51.440
optional auch mit ausführlichem Text, welche die Version der Dateien im Staging-Bereich

04:51.440 --> 04:52.440
beschreibt.

04:52.440 --> 04:58.240
Dies wird dann aus diesem Bereich in das Repository gesichert, eindeutig identifizierbar durch

04:58.240 --> 05:03.360
eine 160-Bit Prüf-Summe, bei welcher auch die ersten sieben Zeichen der Hex-Repräsentation

05:03.360 --> 05:05.280
direkt angezeigt werden.

05:05.280 --> 05:08.560
Diese Kurzform ist in den allermeisten Fällen bereits eindeutig.

05:08.560 --> 05:12.800
Das wiederhole ich nun mit der Datei foo.

05:12.800 --> 05:19.360
Die Commit-Nachricht kann ich mit dem Parameter "-m", direkt über die Kommandozeile eingeben.

05:19.360 --> 05:24.040
Dieser neue Commit wird nun fest als Nachfolger meines vorherigen Commits verankert.

05:24.040 --> 05:29.440
Die Prüfsumme wird nicht nur über die Datei foo gebildet, sondern über den gesamten Verlauf,

05:29.440 --> 05:32.880
also auch inklusive dem vorherigen Commit.

05:32.880 --> 05:37.880
Dadurch kann keine Datei oder Commit geändert oder hinzugefügt werden, ohne dass dieser

05:37.880 --> 05:39.200
Hasch sich ändert.

05:39.200 --> 05:41.400
Die Datenintegrität ist gewährleistet.

05:41.400 --> 05:47.320
Nachdem ich foo geändert und eine neue Datei bar erstellt habe, zeigt mir Git Status eben

05:47.320 --> 05:48.640
dies auch an.

05:48.640 --> 05:53.240
Außerdem sagt mir der Befehl noch, dass ich mich gerade auf dem Zweig Master befinde.

05:53.240 --> 06:00.520
Ich füge beide zum Staging-Bereich hinzu und ändere ohne Commit eine der Dateien.

06:00.520 --> 06:05.320
Nun verfolgt Git auch den Verlauf der Datei bar und merkt, dass es hier Änderungen in

06:05.320 --> 06:08.880
der Datei im Workspace gab.

06:08.880 --> 06:10.720
Änderungen kann man sich auch anzeigen lassen.

06:10.720 --> 06:15.080
Dabei zeigt Git Diff die Änderungen vom Workspace verglichen mit dem Staging-Bereich an.

06:15.080 --> 06:20.920
Ein hinzufügendes Parameter staged vergleicht nun die Staging-Events mit dem neuesten Commit.

06:20.920 --> 06:26.640
Ich füge nun die neueste Änderung wieder in den Staging-Bereich, erstelle einen weiteren

06:26.640 --> 06:29.960
Commit, welcher zwei Dateien gleichzeitig umfasst.

06:29.960 --> 06:35.600
Dadurch kann ich Commits logisch so zusammenfassen, dass sie z.B. immer ein volles Feature enthalten,

06:35.600 --> 06:37.960
auch wenn dies über viele Dreien verteilt ist.

06:37.960 --> 06:43.480
Wenn ich mir die ganze Versionsgeschichte anschauen will, kann ich dies über Git Log

06:43.480 --> 06:49.200
tun, welcher mir Ersteller, Erstellungszeit und Nachricht anzeigt, inklusive dem vollständigen

06:49.200 --> 06:50.560
Commit Hash.

06:50.560 --> 06:55.960
Aber es geht mit Shortlog auch deutlich kompakter, hier werden nur die Kopfzeilen an jeden Commit-Nachricht

06:55.960 --> 06:56.960
ausgegeben.

06:56.960 --> 06:59.400
So weit, so einfach.

06:59.400 --> 07:03.240
Aber wir wollen nun die nicht-lineare Entwicklung genauer beleuchten.

07:03.240 --> 07:06.160
Dazu will ich direkt nach dem ersten Commit abzweigen.

07:06.160 --> 07:12.960
Mit Git Branch kann ich dann den Namen des neu zu erstellenden Zweigs angeben, gefolgt

07:12.960 --> 07:16.200
von dem Commit Hash, bei dem dieser Zweig beginnen soll.

07:16.200 --> 07:19.720
Wenn ich das weglasse, beginne er nach dem aktuellsten Commit.

07:19.720 --> 07:24.080
Der Zweig temp ist erstellt, aber ich befinde mich noch auf Master.

07:24.080 --> 07:26.320
Ich muss noch mit Git Checkout wechseln.

07:26.320 --> 07:32.120
Nun verschwinden in meinem Arbeitsverzeichnis die Dateien foo und bar und ein Git Shortlog

07:32.120 --> 07:35.480
zeigt mir an, dass ich nur einen Commit habe.

07:35.480 --> 07:41.000
Dann legen wir mal eine neue Datei P an und fügen eine Erklärung in der Readme hinzu.

07:41.000 --> 07:48.400
Git add übergebe ich mit dem Punkt einfach schlicht diesen Ordner, damit sind dann beide

07:48.400 --> 07:53.080
Dateien im Staging-Bereich, und mittels Git Commit werden diese dann versioniert, und

07:53.080 --> 07:55.800
zwar als Nachfolger vom ersten Commit.

07:55.800 --> 08:00.560
Allerdings habe ich hier einen Fehler gemacht, die Zahl Pi ist natürlich grob falsch, sie

08:00.560 --> 08:06.120
beginnt mit 3.141, das bessere ich nun aus und möchte den Commit richtig stellen.

08:06.120 --> 08:08.520
Und das erlaubt mir der Parameter Amend.

08:08.520 --> 08:14.080
Dazu auch noch das –a, welches automatisch alle geänderten Dateien stage, so dass ich

08:14.080 --> 08:16.920
mir hier das manuelle Git Add sparen kann.

08:16.920 --> 08:21.640
Wenn ich das ausführe, ändert sich natürlich der Commit Hash, da der Inhalt nun ein anderer

08:21.640 --> 08:22.640
ist.

08:22.640 --> 08:26.760
Aber wir waren eigentlich bei Zweigen.

08:26.760 --> 08:31.360
Wenn ich jetzt durch das ganze Verver vergessen habe, worauf ich arbeite und welche Zweige

08:31.360 --> 08:34.080
es so noch gibt, so hilft mir ein Git Branch.

08:34.080 --> 08:38.200
Um wieder zum Master zurückzukehren, brauche ich nur wieder ein Git Checkout.

08:38.200 --> 08:43.680
Und wie kann ich hier die Änderungen aus dem anderen Zweig im Master einfließen lassen?

08:43.680 --> 08:48.680
Eine Möglichkeit ist der Merge, dazu muss ich den Befehl Git Merge noch die Namen des

08:48.680 --> 08:53.760
anderen Zweiges mit angeben und eine Nachricht spezifizieren, welche aber schon vorausgefüllt

08:53.760 --> 08:54.760
ist.

08:54.760 --> 08:57.160
Und es stellt dafür einen sogenannten Merge Commit.

08:57.160 --> 09:01.880
Wenn ich nun keine Konflikte habe, also nicht die gleichen Dateien in unterschiedlichen

09:01.880 --> 09:04.840
Zweigen geändert habe, klappt das auch ziemlich gut.

09:04.840 --> 09:09.400
Das Log zeigt mir die Geschichte an, Ersteller, Zeit und auch Commit Hashes haben sich nicht

09:09.400 --> 09:12.960
geändert, es gibt nur einen neuen Commit dazu.

09:12.960 --> 09:18.560
Aber das reicht aus, um über die Ästhetik zu streiten, weshalb man manchmal ein anderes

09:18.560 --> 09:22.160
Vorgehen bevorzugt und lieber die Geschichte neu schreiben will.

09:22.160 --> 09:26.080
Wir gehen zurück direkt nach dem Korrektur Commit auf den Zweig Temp.

09:26.080 --> 09:32.640
Mit dem Git Rebase werden nun die anderen Commits vom Master geholt und unser Commit

09:32.640 --> 09:34.520
ans Ende angehängt.

09:34.520 --> 09:38.640
Natürlich ändert sich dadurch der Commit Hash, aber dafür habe ich nun wieder eine

09:38.640 --> 09:42.240
lineare Geschichte und alle Änderungen wie bei Merge.

09:42.240 --> 09:47.080
Nur in der Log-Datei gibt es keinen extra Merge Commit und wir befinden uns gerade auch

09:47.080 --> 09:50.120
noch auf dem Zweig Temp.

09:50.120 --> 09:54.400
Obwohl nun die meisten Git Veteranen viele ihrer liebgewonnen Befehle oder Parameter

09:54.400 --> 09:59.200
vermissen dürften, waren es doch im Beispiel bereits genug, um als Einsteiger erst einmal

09:59.200 --> 10:00.880
überfordert zu sein.

10:00.880 --> 10:06.960
Deshalb hier ein Überblick über die wichtigsten Operationen, um Dateien ein- bzw. auszuchecken.

10:06.960 --> 10:11.720
Mittels Git Add kann eine Datei aus dem aktuellen Arbeitsverzeichnis nach Staging übernommen

10:11.720 --> 10:15.840
werden, ein Commit versioniert dann alle Dateien aus Staging.

10:15.840 --> 10:20.280
Mit Commit-A werden automatisch geänderte und gelöste Dateien übernommen.

10:20.280 --> 10:26.160
Der Befehl Checkout ist etwas überladen, im Beispiel wurde er verwendet, um den Zweig

10:26.160 --> 10:30.760
zu wechseln, aber mit ihm können auch lokale Änderungen an Dateien mit der Version von

10:30.760 --> 10:34.840
Staging oder der des letzten Commits bei Angabe von Head ersetzt werden.

10:34.840 --> 10:41.840
Aber wie anfangs erwähnt, es geht auch dezentral, neben dem lokalen Repo kann man auch noch

10:41.840 --> 10:45.640
ein entferntes Repo, zum Beispiel auf einem Server haben.

10:45.640 --> 10:50.880
Initial kann man sich dieses entfernte Repo komplett klonen, also lokal spiegeln.

10:50.880 --> 10:55.960
Und lokale Commits können mittels Push in das entfernte Repo kopiert werden.

10:55.960 --> 11:01.400
Sofern nun da von anderen Nutzer neue Commits vorliegen, kann die Geschichte zuerst mit

11:01.400 --> 11:05.760
Fetch ins lokale Repo und damit Checkout in den Workspace geladen werden.

11:05.760 --> 11:09.240
Oder man nimmt die Abkürzung Pull, die das in einem Befehl macht.

11:09.240 --> 11:15.620
Für solche entfernten Repos gibt es mittlerweile viele Cloudbasierte Anbieter, der bekannteste

11:15.620 --> 11:20.320
dürfte GitHub sein, die alle zusätzlich mit einer Web-Oberfläche viele Einstellungen

11:20.320 --> 11:24.600
erlauben und schlussendlich dazu dienen, die Kollaboration von mehreren Entwicklern zu

11:24.600 --> 11:25.600
vereinfachen.

11:25.600 --> 11:31.240
Die Zip Amends betreiben im Auftrag des Departments seit Jahren eine GitLab Instanz, welche für

11:31.240 --> 11:36.040
die Lehre verwende werden kann und viele sonst kostenpflichtige Optionen für uns bereitstellt.

11:36.040 --> 11:41.000
Ihr müsst euch dafür nicht extra registrieren, sondern es ist mit dem Identitätsmanagement

11:41.000 --> 11:44.800
der Uni verbunden, ihr könnt euch also direkt über SSO anmelden.

11:44.800 --> 11:49.880
Und hier bekommt ihr auch automatisch nach der Ameltung zur Betriebssystemübung ein

11:49.880 --> 11:51.480
Repo von uns erstellt.

11:51.480 --> 11:55.800
Dieses ist ein Fork von unserer Vorlage, die ihr einfach lokal klonen könnt.

11:55.800 --> 12:01.560
Allerdings ist der Masterzweig im entfernten Repo für euch nicht schreibbar.

12:01.560 --> 12:06.400
Ihr müsst also für jede Aufgabe eine Branch anlegen, auf den ihr dann arbeiten könnt.

12:06.400 --> 12:11.320
Dieser Zweig soll natürlich von euch auch auf GitLab gepusht werden und nachdem ihr

12:11.320 --> 12:16.000
die Aufgabe gelöst habt, könnt ihr über die Web-Oberfläche einen Merchrequest erstellen.

12:16.000 --> 12:20.040
Dadurch werden wir informiert und können eure Abgabe korrigieren.

12:20.040 --> 12:24.640
Sofern alles passt, werden wir sowohl eure Commits als auch die Vorgaben für die Nachfolgen

12:24.640 --> 12:26.960
der Aufgabe in der Master Branch merchen.

12:26.960 --> 12:31.200
Und ihr könnt dann mit der nächsten Aufgabe beginnen, ebenfalls wieder in einem eigenen

12:31.200 --> 12:32.200
neuen Zweig.

12:32.200 --> 12:36.000
Dieser Ablauf am konkreten Beispiel.

12:36.000 --> 12:39.920
Zuerst gehe ich auf die GitLab Webseite in das Übungsrepo und hole mir die URL.

12:39.920 --> 12:45.360
Ich habe bereits einen passwordlosen SSH Zugang eingerichtet, kann also SSH bequem verwenden.

12:45.360 --> 12:49.440
Bei GitClone kann man hinter die URL noch einen Ordner angeben.

12:49.440 --> 12:52.080
Für mich soll das alles in den Ordner mp-stubs wandern.

12:52.080 --> 12:55.920
Dort befinden sich nun die Vorgabedateien.

12:55.920 --> 13:00.760
Ich erstelle mit Checkout-b eine neuen Zweigaufgabe 0 und wechsle auch gleich hinein.

13:00.760 --> 13:02.440
Wo fangen wir an?

13:02.440 --> 13:03.920
Das Wichtigste zuerst.

13:03.920 --> 13:08.800
Ich gehe in Teststream und bearbeite die Makefile so, dass sie mir im Zweifelsfall eine kleine

13:08.800 --> 13:10.120
Motivationsschub gibt.

13:10.120 --> 13:11.120
Speichern.

13:11.120 --> 13:12.120
Ausprobieren.

13:12.120 --> 13:13.120
Funktioniert.

13:13.120 --> 13:20.080
Ich bin voller Zuversicht und füge die Änderungen hinzu.

13:20.080 --> 13:24.920
Minus u erwirkt bei GitAdd, dass die geänderten Dateien nach Staging hinzugefügt werden.

13:24.920 --> 13:29.640
Hier primär als Demonstration, wie viele Varianten man bei Git hat.

13:29.640 --> 13:34.520
Der neue Commit ist erstellt und das will ich nun auf GitLab pushen.

13:34.520 --> 13:38.920
Allerdings haut mir Git auf die Finger, da ich noch keinen Upstream Branch habe.

13:38.920 --> 13:41.640
Sagt mir allerdings auch gleich, wie ich diesen erstellen kann.

13:41.640 --> 13:48.000
In der Meldung wird mir nun auf der Kommandozeile gleich von GitLab ein Link für den Merchrequest

13:48.000 --> 13:49.000
angezeigt.

13:49.000 --> 13:54.480
In der Web-Oberfläche kann ich nun auch den neuen Zweig auswählen und auch meine Änderungen

13:54.480 --> 13:55.480
dort begutachten.

13:55.480 --> 14:00.520
Gut, dann fange ich mal an die Aufgabe ernsthaft zu lösen.

14:00.520 --> 14:04.680
Wechsle in den Ordner Object, um dort die StringBuffer-Header-Datei zu bearbeiten.

14:04.680 --> 14:09.880
Als absoluter Wim-Anfänger schaffe ich es mit nur drei Tasten meine Datei zu lernen

14:09.880 --> 14:11.560
und Speichere und Beenderauschreck.

14:11.560 --> 14:17.120
Ein Git-Diff bestätigt mir, dass alle Zahlen in der Datei gelöscht wurden.

14:17.120 --> 14:21.920
Aber ich habe den vorhin erwähnten Befehl GitCheckOut und kann damit die Datei wieder

14:21.920 --> 14:22.920
herstellen.

14:22.920 --> 14:30.280
Neuer Versuch und nun bearbeite ich zielsicher den Konstruktor, initialisiere die Member-Variable

14:30.280 --> 14:39.440
POS mit Null, speichern, committen mit sinnvoller Meldung, pushen und Fehler.

14:39.440 --> 14:44.960
Die Fehlermeldung ist zum Glück nicht kryptisch, sondern erklärt direkt, dass wohl jemand

14:44.960 --> 14:48.080
anderes in der Zwischenzeit in dieses Repo committet hat.

14:48.080 --> 14:53.680
Zur Sicherheit schaue ich mal auf die Web-Oberfläche und in der Tat, meine Gruppenpartnerin Laura

14:53.680 --> 14:58.720
hat sich natürlich vollkommen zufällig exakt die gleiche Datei vorgenommen, war nur schneller

14:58.720 --> 14:59.720
als ich.

14:59.720 --> 15:01.560
Was mache ich nun?

15:01.560 --> 15:06.200
Es kann ja sein, dass ich schon andere Änderungen habe, oder über die Web-Oberfläche gar nicht

15:06.200 --> 15:08.320
gesehen habe, dass es Änderungen gab.

15:08.320 --> 15:13.120
Ich führe einfach ein Git-Pool aus und mir wird bereits erzählt, dass es Änderungen

15:13.120 --> 15:18.000
im entfernten Repo gab, die mit meinen lokalen Änderungen in Konflikt stehen, konkret in

15:18.000 --> 15:19.480
der Datei string-buffer.h.

15:19.480 --> 15:25.680
In dieser Datei fügt Git nun auch eine spezielle Kennzeichnung ein, bestehend aus größer,

15:25.680 --> 15:26.960
kleiner sowie S-Gleichzeichen.

15:26.960 --> 15:31.520
Ich kann diese nun entweder händisch entfernen oder ich verwende ein dafür vorgesehenes

15:31.520 --> 15:34.960
Merchwerkzeug, wie zum Beispiel das Programm Meld.

15:34.960 --> 15:39.960
Hier haben wir einen 3-Wege-Vergleich, bei dem ich meine Version links, Lauras Version

15:39.960 --> 15:44.120
rechts und den gemeinsamen Vorgänger beider Versionen in der Mitte sehen kann.

15:44.120 --> 15:49.440
Da Lauras Version mit der Initializer-Liste die schönere ist, übernehme ich ihre Änderungen

15:49.440 --> 15:50.440
und Speicher.

15:50.440 --> 15:56.600
Nun gibt es keine weiteren Konflikte mehr, string-buffer.h wurde geändert und es liegt

15:56.600 --> 15:59.520
noch eine Sicherheitskopie mit dem Punkt Oryx-Sophix herum.

15:59.520 --> 16:04.120
Ich committe mit der vorhergesehenen Nachricht und kann weiterarbeiten, zum Beispiel indem

16:04.120 --> 16:05.120
ich das wieder pushe.

16:05.120 --> 16:10.520
Wenn ich nun der Meinung bin, dass die Aufgabe fertig ist, dann erstelle ich einen Merchrequest,

16:10.520 --> 16:13.040
zum Beispiel direkt über den angezeigten Link.

16:13.040 --> 16:15.920
Alternativ kann ich das auch über die Web-Oberfläche auswählen.

16:15.920 --> 16:23.200
Bei Bedarf noch eine kurze Beschreibung zuweisen braucht ihr niemand, darum kümmern wir uns.

16:23.200 --> 16:26.880
Sorgt nur sicher, dass ihr alle relevanten Commits im Zweig auf GitLab habt, wenn ihr

16:26.880 --> 16:28.320
den Merchrequest erstellt.

16:28.320 --> 16:32.960
Er ist dann solange offen, bis ein Übungsleiter Zeit hat ihn zu reviewen.

16:32.960 --> 16:35.560
Ihr könnt ihn selbst natürlich nicht akzeptieren.

16:35.560 --> 16:38.880
Sobald wir fertig sind, bekommt ihr eine Mail.

16:38.880 --> 16:41.080
In diesem Fall hat Chris ihn angeschaut.

16:41.080 --> 16:46.320
Mit unserer Änderung in der Make-File ist er einverstanden, aber ihm ist aufgefallen,

16:46.320 --> 16:50.640
dass noch einige Stücke fehlen, die müssen wir noch nachliefern, bevor er dann den Merchrequest

16:50.640 --> 16:53.160
annimmt und damit die Aufgabe abgeschlossen ist.

16:53.160 --> 16:59.680
Dabei haben wir mit Clone, Push und Pull sowie dem Merch-Tool für den Konflikt nur eine

16:59.680 --> 17:04.360
Handvoll zusätzlicher Befehle gebraucht, um mit dem entfernten GitLab Repo zu arbeiten.

17:04.360 --> 17:10.200
Allerdings solltet ihr vor der ersten Benutzung noch Git konfigurieren, insbesondere eure

17:10.200 --> 17:15.160
Namen und E-Mail, damit die Commits richtig zugeordnet werden können.

17:15.160 --> 17:19.200
Insgesamt lässt sich Git sehr gut an die eigenen Bedürfnisse anpassen, zum Beispiel

17:19.200 --> 17:21.720
Lieblingseditor oder Standard Merch-Tool.

17:21.720 --> 17:25.360
Mit List kann man sich die Konfiguration ansägen lassen.

17:25.360 --> 17:27.080
Außerdem erlaubt Git auch Aliase.

17:27.080 --> 17:31.920
Ich habe bei mir zum Beispiel einen Word Diff erstellt, welches mir statt einer gesamten

17:31.920 --> 17:34.800
Zeile nur die geänderten Zeichen direkt farbig markiert.

17:34.800 --> 17:40.560
Damit man GitLab vernünftig verwenden kann, muss man dort seinen öffentlichen SSH-Schlüssel

17:40.560 --> 17:41.560
eintragen.

17:41.560 --> 17:45.960
Wie man diesen erzeugt, erkläre ich in der ersten Aufgabe im Video-Entwicklungsumgebung.

17:45.960 --> 17:53.080
Git ist vom Konzept her sehr gut durchdacht, allerdings auch eine sehr mächtige und komplexe

17:53.080 --> 17:58.720
Anwendung, welche Anfänger schnell mit der Vielzahl von Befehlen und Parametern überfordert.

17:58.720 --> 18:03.200
Es dauert etwas bis man reinkommt, aber für eine grundlegende Bedienung reichen einige

18:03.200 --> 18:04.840
wenige Befehle aus.

18:04.840 --> 18:09.760
Wir haben am Ende zudem zum Video-gehörigen Folien ein kurzes Cheat-Cheat eingefügt,

18:09.760 --> 18:12.360
das euch hoffentlich beim Einstieg hilft.

18:12.360 --> 18:16.400
Ansonsten findet man auch auf Webseiten wie Stack Overflow oftmals eine Lösung zu den

18:16.400 --> 18:43.400
häufigsten Problemen.