---

Aufgabe Abgabe mit Git

Letzte Änderung: 13. November 2020, 16:25 Uhr
10 Punkte — im Detail
Ansicht:   |  

In der ersten Woche:

1. Suchen Sie sich als erstes eine Übungsgruppe!
2. Loggen Sie sich im Gitlab des Landes RLP (gitlab.rlp.net) ein.
3. Richten Sie in Microsoft Teams einen gemeinsamen Chat ein.

In den Gitlab-Gruppen werden wir automatisiert für jedes Übungsblatt ein neues Git-Repository erstellen in das Sie ihre Abgaben pushen sollten.

Noch ein kurzer Hinweis zu den von uns bereitgestellten Repositories:
Um Verwirrung zu vermeiden haben wir „force-pushes“ auf dem main-Branch für Sie ausgestellt. Der Vorteil ist der, dass ihre Repositories nicht divergieren können, was nur mit etwas mehr Erfahrung wieder lösbar ist und im schlimmsten Fall dazu führt, dass alle Forks und Clones neu initialisiert werden müssen. Der Nachteil ist, dass alle Änderungen auf dem main-Branch damit persistent sind — einmal gepush ist der Commit enthalten, kann aber durch revert wieder mittels eines neuen Commits zurückgezogen werden.

Hinweis:
Auch wenn Sie in dieser Aufgabe etwas falsch machen, können Sie stets den lokalen Ordner des Repositories auf Ihrem Rechner löschen und wieder mit Aufgabenteil 1 anfangen. Sofern Sie ihr Repository nicht gepusht haben, sind alle Änderungen nur lokal!

Nun zur Aufgabe

1. Clonen Sie das Repository, dass nun in Ihrer Untergruppe in Gitlab erscheinen sollte.
2. Fügen Sie die Datei heron.cpp aus der letzten Aufgabe in dieses Repository ein und pushen Sie die Änderungen auf den Server.
3. Ein typischer Fall ist der Folgende: Sie und eine weitere Person (z.B. Ihr(e) Abgabepartner(in)) arbeiten an der selben Datei — schlimmer noch, sie arbeiten an der selben Zeile in der selben Datei.
   
   Sorgen Sie zuerst dafür, dass beide Personen den selben Repository-Status auf ihrem Rechner haben. (Alternativ können Sie auch in zwei verschiedenen Ordnern jeweils clonen bzw. pullen)
   1. Ersetzen Sie in beiden Repositories denselben Variablennamen durch einen jeweils unterschiedlichen Namen.
   2. Committen Sie beide die Änderung (noch nicht pushen!).
   3. Nun pusht die eine Person die Änderung.
   4. Die andere Person kann nicht pushen, da der main-Branch divergiert ist (sie können es ruhig versuchen). Lösen Sie den Konflikt durch Ausführung des Befehls git pull. (Den Ordner löschen und die Änderung auf dem neuen Commit ausführen ist nicht erlaubt! Es geht hier darum den merge-Konflikt selbst zu lösen. ;) )
4. Etwas schwieriger, aber auch typischer Fall — diesmal bei der Zusammenarbeit mit fremden Personen, also solchen, die keinen Zugriff auf Ihr eigenes Repository haben:
   Wie Sie vielleicht bemerkt haben, sind die Repositories sog. Forks eines anderen öffentlichen Repositories (dies wird in der Weboberfläche unter dem Repository-Namen angezeigt). Bei Änderungen von vorgegebenem Code werden wir das Ursprungsrepository abändern, dass Sie dann wiederum „fetchen“ und in Ihr Repository einpflegen können. Dies ist übrigens auch die übliche Form von Kollaboration auf Github.com oder ähnlichen Anbietern von Git-Repositories.
   
   Wir möchten nun einen solchen Fall simulieren;
   Das Szenario ist wie folgt. Sie haben ein Repository geforkt, weil Sie das dort hinterlegte Tool interessant fanden.¹ Wir nehmen an, Sie haben bereits ein Feature in das Projekt eingebaut und als Commit in Ihr Repository eingepflegt.² Ein typisches Problem ist nun, dass das Team, das noch nichts von Ihren Änderungen weiß weiter an dem Projekt gearbeitet hat und in das offizielle Repository, zu dem Sie typischerweise keinen Zugriff haben, gepusht haben.³ In unserer Simulation befindet sich das offizielle Repository des Projektes unter http://gitlab.rlp.net/eis20/materialien/blatt01-fork.
   
   Nun zur eigentlichen Aufgabe:
   Fügen Sie dieses Repository lokal als weiteres „remote“-Repository ein, fetchen dessen Änderungen und mergen Sie diese Änderungen in ihr Repository ein.
   Vergessen Sie nicht zu pushen wenn sie fertig sind!
   
   Sie können selbst prüfen, ob Sie alles richtig gemacht haben⁴:
   • bei einem richtigen Merge sollte Ihr Repository nun eine Abzweigung im Verlauf haben:

     > git tree
     *       71287f0 2020-04-19 (HEAD -> main)  Merge remote-tracking branch 'fork/main' (Christian Ali Mehmeti-Göpel)
     |\  
     | *     4a8d0ff 2019-04-17 (fork/main)  README changed (Christian Ali Mehmeti-Göpel)
     * |     3b0e32c 2020-04-19  IHRE COMMIT MESSAGE (IHR NAME)
     |/  
     *       f07be10 2019-04-17 (origin/main, origin/HEAD)  Initial commit (Christian Ali Mehmeti-Göpel)
     

   • So am Rande: bei einem richtigen Rebase würde die Historie wie folgt aussehen:

     > git tree
     *       f27cbbc 2020-04-19 (HEAD -> main)  IHRE COMMIT MESSAGE (IHR NAME)
     *       4a8d0ff 2019-04-17 (remote/main)  README changed (Christian Ali Mehmeti-Göpel)
     *       f07be10 2019-04-17 (origin/main, origin/HEAD)  Initial commit (Christian Ali Mehmeti-Göpel)
     

     Wie sie sehen gibt es keine Abzweigungen und das vor und zurückspringen ist deutlich einfacher als bei einem verzweigten Versionsbaum.
   • In beiden Fällen ist es jedoch so, dass die Commit-IDs des Forks übernommen werden.
     Mit anderen Worten: die Änderung, die Sie in Ihr eigene Repository eingepflegt haben sind die tatsächlichen Änderungen — für git sind es ein und der selbe Commit und weiteres mergen/rebasen ist ohne weiteres möglich, da die bereits eingepflegten Commits nicht mehr auf Korrektheit überprüft werden müssen. Der einzige Nachteil eines Rebases⁵ behsteht darin, dass es sich nicht mehr um Ihren ursprünglichen Commit, sondern eine Kopie aller Änderungen, handelt — dies ist daran zu beobachten, dass sich die Commit-Id vor und nach einem Rebase ändert.

---

[1] Genau wie das Lerngruppen-Repository, an dem Sie gerade arbeiten.
[2] Genau wie in Aufgabenteil 2.
[3] Sie planen noch das Team des Projektes zu bitten, Ihr Feature in den offiziellen zweig einzubinden. Dies ist aber noch nicht geschehen.
[4] Einen Befehl den ich stets vielen Empfehle ist git tree. Dieser gibt Ihnen die Versionshistorie wie oben angezeigt auf der Konsole aus. Sie erhalten diesen Befehl, wenn sie ihn einmalig als git-alias wie folgt setzen:

git config --global alias.tree 'log --graph --full-history --all --color --date=short'

[5] Ein anderer Nachteil ist die etwas etwas anderen Verwendung. Aus dem Grund soll in dieser Aufgabe lediglich das Repository gemerged werden.