Aufgabe 16 - Git II - Abzweigungen

Aufgabe 16 - Git II - Abzweigungen

Worum geht es?

Branches, Merges und der erste absichtlich herbeigeführte Merge-Konflikt, im Zweierteam über ein gemeinsames Remote-Repository am Schul-GitLab (siehe Kapitel Versionsverwaltung mit Git). Konflikte gelten als der Schrecken von Git-Anfängern; nach dieser Übung wissen Sie aus eigener Erfahrung, dass sie ein kontrollierbarer Normalfall paralleler Arbeit sind.

Was Sie dafür brauchen

• Kapitel Versionsverwaltung mit Git, Abschnitte Branches, Konflikte und Remotes; Aufgabe 15.
• Ein Zweierteam und ein gemeinsames Repository am Schul-GitLab (eine Person legt es an und lädt die andere als Mitglied ein).

Welche Kompetenzen Sie erwerben und zeigen

• Sie legen Branches an, wechseln zwischen ihnen und führen sie mit Merge zusammen.
• Sie arbeiten über ein Remote-Repository im Team (clone, push, pull).
• Sie lösen Merge-Konflikte kontrolliert und dokumentieren das Vorgehen.

Pädagogische Einordnung

• Reproduktion: die Branch-Kommandos ausführen und ihre Wirkung beschreiben (Teil A).
• Reorganisation und Transfer: den Team-Workflow über das Remote anwenden und Konfliktsituationen bearbeiten (Teile B und C).
• Reflexion, Problemlösung und Urteilsbildung: eine verzwicktere Synchronisationslage selbstständig auflösen und Teamregeln ableiten (Teil D).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt und wird durchgehend im Zweierteam bearbeitet. Teil D ist der Expertenteil.

Teil A - Branch-Grundlagen (jede Person für sich)

1. Klonen Sie das gemeinsame Repository. Legen Sie einen Branch feature/greeting an und wechseln Sie mit git switch darauf.
2. Ändern Sie dort eine Datei, committen Sie, und wechseln Sie zurück auf main: Die Änderung ist scheinbar verschwunden. Erklären Sie in einem Satz, wo sie ist, und prüfen Sie Ihre Erklärung mit git log --oneline --all.
3. Mergen Sie den Branch nach main (git merge feature/greeting) und löschen Sie ihn danach mit git branch -d.

Teil B - Zusammenarbeit ohne Konflikt

1. Person A und Person B arbeiten gleichzeitig, aber in verschiedenen Dateien, jeweils auf einem eigenen Feature-Branch mit sprechendem Namen.
2. Beide mergen nach main und pushen; wer beim Push abgewiesen wird, holt zuerst mit pull den neuen Stand.
3. Ziehen Sie abschließend beide den Endstand und prüfen Sie mit git log --oneline --graph, dass beide Historien identisch sind. Halten Sie die verwendete Kommandofolge schriftlich fest.

Teil C - Der Konflikt

1. Jetzt absichtlich: Beide ändern auf eigenen Branches dieselbe Zeile derselben Datei (etwa den Programmtitel; A nennt ihn “Media Library 2000”, B “SuperMedia”).
2. Person A merged zuerst nach main und pusht (funktioniert). Person B pullt, merged und erhält den Konflikt.
3. Person B löst ihn: Konfliktmarker (<<<<<<<, =======, >>>>>>>) lesen, gemeinsam entscheiden, welche Fassung gilt (oder eine dritte), Marker entfernen, Programm testen, add, commit, push.
4. Tauschen Sie die Rollen und provozieren Sie einen zweiten Konflikt, diesmal mit einer Kombination beider Fassungen als Lösung.

Teil D - Expertenteil: Verzwickte Lagen und Teamregeln

1. Stellen Sie folgende Situation her und lösen Sie sie: Beide committen direkt auf main (ohne Branch), Person A pusht zuerst. Person B wird beim Push abgewiesen, und der anschließende pull erzeugt einen Konflikt außerhalb eines selbst gestarteten Merges. Lösen Sie die Lage und beschreiben Sie, worin sie sich vom Konflikt aus Teil C unterscheidet.
2. Untersuchen Sie Ihre Historie mit git log --oneline --graph: Identifizieren Sie einen Merge-Commit und seine zwei Eltern. Skizzieren Sie den Graphen auf Papier und beschriften Sie, welcher Zweig welcher war.
3. Verfassen Sie zu zweit einen halbseitigen Merkzettel “Konflikt-Erste-Hilfe” für Ihre Klasse: Woran erkenne ich einen Konflikt? Welche drei Schritte lösen ihn? Was tue ich nie (etwa: blind eine Seite löschen, Marker committen)?
4. Leiten Sie drei Teamregeln für Ihre künftigen Projekte ab (Branch-Namenskonvention, Merge-Rhythmus, wer löst Konflikte) und begründen Sie jede mit einer Erfahrung aus dieser Übung.

Wissenscheck

1. Was ist ein Branch technisch, und warum ist das Anlegen praktisch gratis?
2. Wann erzeugt ein Merge einen Konflikt, und wann läuft er automatisch durch?
3. Warum darf eine Datei mit Konfliktmarkern niemals committet werden?
4. Ihr Push wird mit “rejected” abgewiesen. Was ist passiert, und was ist die korrekte Reaktion?
5. Warum bleiben Konflikte klein, wenn Branches kurzlebig sind und oft gemergt wird?

Abgabe

Link zum gemeinsamen Repository (die Historie muss beide Merges, beide Konfliktauflösungen und die Lage aus Teil D zeigen), der Graph aus Teil D, der Merkzettel und die drei Teamregeln.