U15 — Workflow-Training III: Zusammenarbeit im Tandem

Ziel dieser Übung

Bisher haben Sie den Git-Workflow allein durchlaufen. Der eigentliche Zweck von Git ist aber die Zusammenarbeit: Zwei Personen arbeiten gleichzeitig am selben Projekt, ohne sich Dateien per USB-Stick oder Mail zu schicken. In kurzen Ping-Pong-Runden wechseln Sie sich mit Ihrem Tandempartner ab — jede Runde ist ein kompletter Roundtrip und in wenigen Minuten erledigt. Nebenbei bekommt Ihre Website einen professionellen Feinschliff.

Voraussetzungen: Beide Partner haben u12 (VS Code & Git) abgeschlossen. Beide sind als Mitarbeiter im selben Forgejo-Repository eingetragen (Settings → Collaborators — das haben Sie in u5/Sitzung 3 erledigt).

Das Mantra dieser Übung: Immer erst Sync, dann arbeiten.

Ablauf im Überblick

1Aufwärmrunde: Änderung wandert von Laptop zu Laptop
2Ping-Pong: abwechselnd Feinschliff-Punkte umsetzen
3Bonus: einen Merge-Konflikt absichtlich erzeugen & lösen
4Abschluss: README, Server-Pull, Live-Check
Runde 0 — Aufwärmen: die Magie der Synchronisation (ca. 10 Min.)

lokal Beide Partner: Stand angleichen

Beide öffnen das Projekt in VS Code und klicken Sync Changes — jetzt haben beide exakt denselben Stand.

lokal Partner A: kleine Änderung

  1. Fügen Sie in der index.html einen Kommentar ein: <!-- Gruß von Partner A -->
  2. Stage → Commit (Gruss von A) → Sync

lokal Partner B: nur synchronisieren

  1. Klicken Sie Sync Changes
  2. Öffnen Sie index.html — der Kommentar von A ist da. Ohne USB-Stick, ohne Mail.
  3. Jetzt umgekehrt: B fügt einen Gruß ein, committet, synct — A holt ihn per Sync

git Kurzer GUI-Check

Auf git.md-phw.de: Beide Commits sichtbar? Wer hat was committet? (Forgejo zeigt den Autor neben jedem Commit — deshalb war die git config user.name-Einstellung wichtig.)

Runden 1–6 — Ping-Pong-Feinschliff (je ca. 5–10 Min. pro Punkt)

Jetzt wird abwechselnd gearbeitet: Partner A nimmt Punkt 1, Partner B gleichzeitig Punkt 2 — aber an unterschiedlichen Dateien! Nach jedem fertigen Punkt: Commit → Sync → der Partner synct ebenfalls. So bleibt ihr ständig auf demselben Stand.

Feinschliff-Liste (Reihenfolge frei, abwechselnd ziehen):

  1. Eigene 404-Seite: 404.html im Stil eurer Website („Seite nicht gefunden“ + Link zur Startseite)
  2. Footer mit Stand: einheitlicher Footer auf allen Seiten, z. B. „Zuletzt aktualisiert: Juni 2026“ + Link zum Impressum
  3. Alt-Texte: alle <img>-Tags bekommen ein sinnvolles alt-Attribut (Barrierefreiheit!)
  4. Meta-Description: <meta name="description" content="..."> im <head> jeder Seite (max. 160 Zeichen)
  5. Seitentitel prüfen: jede Seite hat einen eigenen, sprechenden <title>
  6. Link-Check: alle internen Links durchklicken — tote Links reparieren

lokal Pro Punkt — immer derselbe Ablauf

  1. Sync (erst holen, was der Partner gemacht hat!)
  2. Punkt umsetzen, lokal im Browser testen
  3. Stage → Commit mit sprechender Nachricht (z. B. 404-Seite ergaenzt) → Sync
  4. Dem Partner Bescheid geben: „gepusht!“

git Nach jeder Runde

Kurzer Blick ins Forgejo-GUI: Commits beider Partner in der Historie? Wechseln sich die Autoren ab? So sieht gelebte Zusammenarbeit aus.

Bonus-Runde — der kontrollierte Konflikt (ca. 15 Min., für mutige Tandems)

Was passiert, wenn beide dieselbe Zeile ändern? Ein Merge-Konflikt. Den erzeugen wir jetzt absichtlich — damit Sie ihn im geschützten Rahmen kennenlernen, nicht im Ernstfall.

lokal Konflikt erzeugen

  1. Beide Partner: Sync (gleicher Stand!)
  2. Partner A ändert den <title> der index.html in Team Rakete → Commit → Sync
  3. Partner B ändert denselben <title> in Team Blitz — ohne vorher zu syncen! → Commit → Sync
  4. Bei B meldet VS Code jetzt einen Konflikt — die Datei erscheint unter „Merge Changes“

lokal Konflikt lösen (Partner B, gemeinsam besprechen!)

  1. Öffnen Sie die Datei — VS Code markiert den Konflikt farbig:
    <<<<<<< HEAD (eure Version) <title>Team Blitz</title> ======= <title>Team Rakete</title> >>>>>>> (Version des Partners)
  2. VS Code bietet darüber Klick-Optionen an: Accept Current Change (eure) / Accept Incoming Change (Partner) / Accept Both
  3. Entscheidet euch gemeinsam für eine Version — oder schreibt eine dritte (z. B. Team Blitz-Rakete)
  4. Speichern → Stage → Commit (Konflikt geloest: Titel geeinigt) → Sync
  5. Partner A: Sync — die geeinte Version kommt an

Merken: Ein Konflikt ist kein Fehler, sondern eine Rückfrage: „Zwei Menschen, eine Zeile — wie hättet ihr es gern?“ Vermeiden lässt er sich fast immer durch das Mantra: erst Sync, dann arbeiten.

Abschlussrunde — dokumentieren & live bringen (ca. 10 Min.)

lokal README aktualisieren

Ergänzen Sie gemeinsam (einer tippt): neue Dateien (404.html?), neue Features (Footer, Meta-Tags). Commit → Sync.

git Struktur-Abgleich

Stimmt die README mit dem Repo-Inhalt überein? Zeigt die Commit-Historie beide Autoren im Wechsel?

server Live bringen

ssh -p 2222 isa##@edumake.de cd ~/public_html git pull git log --oneline -8 # beide Autoren sichtbar?

Browser mit Hard Reload (Strg/Cmd + Shift + R): Footer da? 404-Seite testen: einfach https://isa##.edumake.de/gibtsnicht.html aufrufen.

Vertiefung für Zwischendurch

learngitbranching.js.org — interaktives Git-Lernspiel (auf Deutsch): Commits, Branches und Merges visuell nachvollziehen, Level für Level. Ideal, um das Verständnis hinter den Klicks aufzubauen.

Weiterführende Links