# Aufgabe: Mit Git zusammen arbeiten. --- 1. Der Hund sitzt im Eiscafé. 2. Die Katze steht vor dem Supermarkt. --- In dieser Aufgabe simulieren wir den Prozess, wie es ablaufen kann, wenn man git nutzt um im Team zusammen zu arbeiten. In der ersten Runde geht es darum, Merge-Konflikte zu provozieren Vorbereitung in der Gruppe: Es werden Teams von 2-4 Personen gebildet. Jedes Team bekommt einen Satz, der den Anfang einer Geschichte bildet. Jedes Team arbeitet in einem Breakout-Room. Vorbereitung: * Wechsle das Verzeichnis. * Clone das github-Verzeichnis. ```$ git clone git@github.com:zweifeln/lern_git.git``` In deinem Ordner befindet sich nun eine Kopie des Repositories. Führe ```$ git remote -v ``` aus um zu Prüfen, ob deine Kopie mit dem richtigen Remote verbunden ist. Hier sollte die URL von oben stehen. Ist dies nicht der fall, kannst du sie mit folgendem Befehl hinzufügen: ```$ git remote add origin <url>``` ## Runde 1: Lösen von Merge-Konflikten * Eine Person erstellt die Datei <Tier>.md mit dem entsprechenden Satz, pusht und mergt. * Alle pullen die Veränderung. * Alle erstellen lokal einen Branch und ändern etwas in der Datei, zB durch zufügen von Sätzen innerhalb der selben Zeile, oder Änderung von einzelnen Worten. * **Nacheinander** eröffnen alle einen Pull Request und versuchen, die Änderung zu mergen. Hier sollte es zu einem Konflikt kommen! * Der Konflikt wird gelöst in dem entweder eine von beiden Änderungen, beide Änderungen oder eine Mischform übernommen wird. Dann wird gemergt. --- ## Runde 2: * Das Team stimmt sich kurz zusammen ab, wie die vorhandene Geschichte fortgeführt werden soll, wer für die entsprechende Änderung verantwortlich ist. Dabei bleiben die Umsetzungsdetails den einzelnen überlassen. * Nacheinander implementiert jede Person ihre Änderungen mit folgendem Vorgang: ``` $ git pull $ git branch <branch-name> $ git checkout <branch-name> ``` * Änderungen in der Datei ``` $ git commit -m "..." $ git push ``` * auf github: - PR öffnen * Alle reviewen den PR von einer anderen Person aus dem eigenen Team. Die reviewende Person kann Änderungsvorschläge machen oder den PR direkt akzeptieren. * Hier sollte es zu weniger merge Konflikten kommen!