Kollaboratives Arbeiten mit GitHub III

rstatsZH - Data Science mit R

Lars Schöbitz

Jul 21, 2026

Lernziele

  1. Ihr könnt eine Branch erstellen, darauf committen und einen Pull Request gegen main öffnen.
  2. Ihr könnt einen Pull Request einer anderen Person reviewen (durchsehen) und mit mindestens einem Kommentar kommentieren.
  3. Ihr könnt erklären, wann ein Merge-Konflikt entsteht, und einen Konflikt in einer gemeinsam bearbeiteten Datei auflösen.

Worum geht es heute?

  • Ihr seid zu viert (ihr + ich) in einer GitHub-Organisation mit Schreibrecht auf ein Repository.
  • Ihr arbeitet gemeinsam an einem Bericht (bericht.qmd).
  • In 60 Minuten erlebt ihr Branching, Pull Requests, Review und Merge.

Der gemeinsame Bericht

bericht.qmd besteht aus:

  • einem Titelblock oben,
  • vier Abschnitten, einer pro Person.

Note

Wir wechseln bei jedem Schritt zwischen “Ich bin dran” (ich zeige es vor) und “Ihr seid dran” (ihr macht es selbst).

Spielregeln

  • Vier Issues, eines pro Person, klar zugewiesen.
  • Branch-Namen: issue-N-<slug> (z. B. issue-3-methoden). Ein Slug ist ein einzelnes Wort, das das Issue beschreibt.
  • main ist geschützt: Merge nur über einen Pull Request mit mindestens einer Review.
  • Jeder Pull Request wird von einer anderen Person reviewt, nie der eigene.
  • Lars ist Admin und merged die Pull Requests.

Ablauf

Ablauf (60 Minuten)

Zeit Schritt
0–10 Min Einstieg, Bericht zeigen, Repository klonen, Issue gemeinsam suchen
10–20 Min Branch erstellen (ich zeige, dann ihr)
20–30 Min Quiet Mode: eigener Abschnitt (ihr seid dran)
30–40 Min Pull Request öffnen, Reviewer markieren (ich, dann ihr)
40–50 Min Review mit mindestens einem Kommentar (ich, dann ihr)
50–55 Min Live-Merge gemeinsam
55–60 Min Fragerunde

Schritt 1: Repository klonen — Wir sind dran

Wir starten auf GitHub und holen das Team-Repository gemeinsam nach Posit Cloud.

  1. Öffne auf GitHub das Team-Repository team-lila.
  2. Klicke auf Code und kopiere die HTTPS-URL.
  3. Öffne den Kursarbeitsbereich auf posit.cloud.
  4. Klicke auf New Project und dann auf New Project from Git Repository.
  5. Füge die URL ein und bestätige, bis du bericht.qmd siehst.

Schritt 2: Issue finden

Das machen wir gemeinsam.

  1. Öffne das gemeinsame Repository auf GitHub.
  2. Gehe zum Reiter Issues.
  3. Finde das Issue, das dir zugewiesen ist.
  4. Lies, welchen Abschnitt du schreiben sollst.

Schritt 3: Branch erstellen — Ich bin dran

Ich zeige die Schritte einmal vor (5 Minuten).

Schritt 3: Branch erstellen — Ihr seid dran

  1. Erstelle eine neue Branch mit dem Namen issue-N-<slug>.
  2. N ist die Nummer deines Issues, <slug> ein einzelnes Wort, das das Issue beschreibt.
  3. Wechsle auf deine Branch (lokal oder auf posit.cloud).

Schritt 4: Quiet Mode — Ihr seid dran

  1. Schreibe deinen eigenen Abschnitt in bericht.qmd.
  2. Committe deine Änderungen auf deine Branch.

Wer reviewt wen?

PR-Autor:in (Abschnitt) Reviewer:in
antonella-antonella (Unfälle pro Jahr) caro316
NOnina1 (Schwere nach Beteiligung) antonella-antonella
caro316 (Tödliche Unfälle) rainbow-train
rainbow-train (Fuss- und Velounfälle) NOnina1

Schritt 5: Pull Request öffnen — Ich bin dran

Ich zeige die Schritte einmal vor (5 Minuten).

Schritt 5: Pull Request öffnen — Ihr seid dran

  1. Öffne einen Pull Request von deinem Branch gegen main.
  2. Markiere eine andere Person als Reviewer.
  3. Verlinke dein Issue im Pull Request (z. B. Closes #N).

Schritt 6: Review — Ich bin dran

Ich zeige einmal, wie eine Review aussieht (5 Minuten).

Schritt 6: Review — Ihr seid dran

  1. Öffne den Pull Request, der dir zur Review zugewiesen wurde.
  2. Lies die Änderungen im Reiter Files changed.
  3. Hinterlasse mindestens einen Kommentar.
  4. Gib die Review frei (Approve oder Kommentar).

Schritt 7: Live-Merge

  • Ich merge die Pull Requests gemeinsam mit euch der Reihe nach.
  • Wenn zwei Branches dieselbe Stelle geändert haben, kann dabei ein Merge-Konflikt entstehen.
  • Falls das passiert, lösen wir ihn gemeinsam auf.

Merge-Konflikte

Was ist ein Merge-Konflikt?

  • Zwei Branches ändern dieselbe Stelle einer Datei unterschiedlich.
  • Git kann nicht selbst entscheiden, welche Version gewinnt.
  • Git markiert die Stelle und bittet uns um die Entscheidung.

So sieht ein Konflikt aus

<<<<<<< main
- Quelle A (Statistik Kanton Zürich)
=======
- Quelle B (Bundesamt für Statistik)
>>>>>>> issue-3-methoden
  • Oben die Version aus main.
  • Unten die Version aus deiner Branch (issue-3-methoden).
  • Git hat drei Markierungen eingefügt: <<<<<<<, ======= und >>>>>>>.

Konflikt auflösen: Markierungen entfernen

Wir entscheiden uns und löschen die markierten Zeilen:

<<<<<<< main
- Quelle A (Statistik Kanton Zürich)
=======
- Quelle B (Bundesamt für Statistik)
>>>>>>> issue-3-methoden
  • Weg kommen die drei Markierungszeilen.
  • Und die Version, die wir nicht behalten wollen.

Konflikt auflösen: Was bleibt

Wir behalten hier die Version aus issue-3-methoden:

- Quelle B (Bundesamt für Statistik)
  • Übrig bleibt eine saubere Zeile, ohne Markierungen.
  • Danach bericht.qmd speichern, committen und den Merge abschliessen.

Note

Manchmal wollen wir beide Einträge behalten. Dann entfernen wir nur die drei Markierungszeilen und lassen Quelle A und Quelle B stehen.

Reflexion

  • Wozu dienen Branches, wenn mehrere Personen am selben Repository arbeiten?
  • Wie hilft eine Review dabei, Probleme früh zu erkennen?
  • Wann kann ein Merge-Konflikt entstehen, und was bedeutet er?

Fragerunde

Was ist noch offen?

Zeit für eure Fragen (5 Minuten).

Geschafft

Ihr habt gemeinsam an einem Bericht gearbeitet, ohne euch gegenseitig zu überschreiben.

Genau dafür sind Branches, Pull Requests und Reviews da.

Danke

Danke!

Folien erstellt mit revealjs und Quarto: https://quarto.org/docs/presentations/revealjs/

Folien als PDF auf GitHub

Alle Materialien sind lizenziert unter Creative Commons Attribution Share Alike 4.0 International.