Git im Griff

Worum es geht

Git kann mehr, als die meisten Teams nutzen. Die Folge sind unnötige Merge-Konflikte, Commit-Historien, die nicht erklären, warum sich etwas geändert hat, und Entwicklungsmodelle, die bremsen, statt zu beschleunigen. Und seit KI-Agenten Code schreiben, arbeiten nicht mehr nur Menschen parallel an derselben Codebasis.

In dieser Schulung verstehst du, was beim Merge wirklich passiert, räumst Historien auf, bevor du sie teilst, und lernst erprobte Branching-Strategien kennen. Du legst fest, was in dein Repository gehört und was in ein Release. Mit Git Worktrees arbeitest du parallel an mehreren Aufgaben, und mehrere Agenten kommen sich dabei nicht in die Quere. Zum Schluss gehst du auf Spurensuche und findest mit git bisect die Änderung, die einen Fehler eingeführt hat.

So arbeitest du

Zuschauen reicht dafür nicht. Jede Sitzung beginnt mit einer Vorführung von höchstens 40 Minuten, danach arbeitest du 60 bis 75 Minuten selbst im Terminal, an vorbereiteten Repositories und ohne Folien. Die Aufgaben haben zwei Stufen, sodass du weiterarbeiten kannst, wenn du früher fertig bist, ohne dass die Gruppe auseinanderläuft. In den Sitzungen 2 und 5 arbeitest du zu zweit gegen ein gemeinsames Remote-Repository, damit Konflikte so entstehen wie im Team und nicht wie im Lehrbuch.

Die Diskussion am Ende jeder Sitzung geht von den Fehlern und Überraschungen der Übung aus.

Ablauf

1. 1

   Sitzung 1: Gute Commits, saubere Historie

   Was ist ein guter Commit, und wie räumst du auf, bevor du teilst?

   • Semantische Commits: eine logische Änderung je Commit, Nachrichten, die das Warum erklären
   • Änderungen gezielt zusammenstellen mit git add -p
   • Eine Historie aufräumen: git commit --fixup, git rebase -i mit --autosquash, Commits teilen, umsortieren und zusammenfassen
   • Wann Historie umgeschrieben werden darf: lokal ja, geteilt nein
   • Das Reflog als Sicherheitsnetz: Verloren ist nur, worauf nie etwas gezeigt hat

   Ergebnis: Eine unaufgeräumte Folge von Commits, umgebaut zu Commits, die je eine Änderung mit ihrem Grund beschreiben, und ein verlorener Commit, über das Reflog zurückgeholt

2. 2

   Sitzung 2: Was beim Merge wirklich passiert

   Wie entsteht ein Konflikt, und wie löst du ihn, statt zu raten?

   • Unter der Haube: Commits, Trees und Blobs; Branches und Tags als Zeiger
   • Gemeinsamer Vorfahre, Fast-Forward, Merge-Commit, Rebase, Cherry-Pick
   • Wie Konflikte entstehen, wie du sie liest, etwa mit merge.conflictStyle=zdiff3, und wie du sie auflöst
   • Wiederkehrende Konflikte mit git rerere nur einmal lösen
   • Merge oder Rebase: Folgen für Historie und Review

   Ergebnis: Konflikte, die du zu zweit gegen ein gemeinsames Remote-Repository erzeugt, erklärt und aufgelöst hast, und die vorbereiteten Konfliktszenarien, einmal mit Merge und einmal mit Rebase gelöst

3. 3

   Sitzung 3: Ein Entwicklungsmodell für dein Team

   Wie arbeitet ihr zusammen, ohne in der Merge-Hölle zu landen?

   • Strategien gegen die Merge-Hölle: kurzlebige Branches, häufig integrieren, Unfertiges hinter einem Schalter statt in einem langlebigen Branch
   • Trunk-Based Development: Voraussetzungen und Folgen
   • Feature- und Release-Branches: wann sie nötig sind, etwa bei mehreren unterstützten Versionen
   • Bewährte Praktiken aus der Open-Source-Entwicklung, etwa aus der Pflege von PHPUnit: einen Fehler auf dem ältesten betroffenen Branch beheben und nach oben zusammenführen

   Ergebnis: Die begründete Wahl eines Entwicklungsmodells nach Teamgröße, Release-Kadenz und Zahl unterstützter Versionen, und ein Fix, den du vom ältesten von drei Release-Branches nach oben zusammenführst und zum Vergleich per Cherry-Pick verteilst

4. 4

   Sitzung 4: Repositories, Abhängigkeiten und Releases

   Was gehört in welches Repository, und was in ein Release?

   • In wie vielen Repositories wollt ihr arbeiten? Ein Repository oder viele, und was das für die Zusammenarbeit über Teamgrenzen bedeutet
   • Ein Paket mit seiner Historie aus einem Repository herauslösen: git subtree split, git filter-repo
   • Abhängigkeiten und Versionskontrolle: composer.lock gehört bei Anwendungen ins Repository, vendor/ nicht; Submodule und Subtrees im Vergleich zu Composer
   • Releases: annotierte und signierte Tags, Versionsnummern
   • .gitattributes mit export-ignore und git archive: Was landet im ausgelieferten Paket, und was nicht?

   Ergebnis: Ein Paket, mit seiner Historie aus einem Monorepo herausgelöst und per Composer wieder eingebunden, und ein getaggtes Release, dessen Archiv weder Tests noch Werkzeugkonfiguration enthält

5. 5

   Sitzung 5: Parallel arbeiten mit Worktrees und KI-Agenten

   Wie arbeiten mehrere Menschen und Agenten gleichzeitig, ohne sich in die Quere zu kommen?

   • Git Worktrees: mehrere Arbeitsverzeichnisse zu einem Repository anlegen, auflisten und entfernen
   • Eine Aufgabe, ein Branch, ein Worktree: warum Agenten sich so nicht gegenseitig stören
   • Was sich Worktrees teilen und was nicht: Repository und Branches gemeinsam, Arbeitsverzeichnis, Abhängigkeiten und Build-Artefakte getrennt
   • Mehrere Coding Agents parallel arbeiten lassen und ihre Ergebnisse prüfen
   • Parallel entstandene Branches zusammenführen: Reihenfolge, Konflikte zwischen Agenten, kleine Commits als Voraussetzung für Reviews
   • Aufräumen: Worktrees und Branches nach der Integration

   Ergebnis: Mindestens drei Aufgaben, parallel in getrennten Worktrees bearbeitet, von Agenten oder von Hand, und in einer festgelegten Reihenfolge zusammengeführt, auch die eine, die mit einer anderen kollidiert

6. 6

   Sitzung 6: Archäologie und Auswertungen

   Was verrät die Historie über Fehler und über dein Projekt?

   • Fehlersuche mit git bisect, von Hand und automatisiert mit git bisect run und einem Test
   • Suchen in der Zeit: git grep, auch in früheren Versionen, und git log -S und -G für die Frage, wann etwas eingeführt oder entfernt wurde
   • git blame sinnvoll lesen: Umformatierungen und Verschiebungen ausblenden mit -w, -C und --ignore-revs-file
   • Auswertungen der Historie: Wer ändert was, wie oft, wo konzentrieren sich Änderungen, und welche Dateien ändern sich gemeinsam?
   • Visualisierungen der Historie

   Ergebnis: Der Commit, der den Fehler im Übungsrepository eingeführt hat, gefunden mit git bisect von Hand und automatisiert, und die Auswertung der Historie deines eigenen Projekts im Vergleich mit denen der anderen

Für wen

• Entwicklerinnen und Entwickler, die Git bereits im Alltag nutzen und mehr daraus machen wollen
• Teams, die mit Merge-Konflikten und langlebigen Branches kämpfen
• Tech Leads, die ein Entwicklungsmodell für ihr Team auswählen oder überprüfen wollen
• Entwicklerinnen und Entwickler, die mehrere KI-Agenten parallel arbeiten lassen wollen
• Mitwirkende an Open-Source-Projekten und alle, die Pakete veröffentlichen

Voraussetzungen

• Praktische Erfahrung mit Git oder einer anderen verteilten Versionskontrolle
• Für die Übungen Git, ein Terminal und ein Editor deiner Wahl
• Für die Übungen mit PHP-Projekten zusätzlich PHP und Composer, wahlweise im bereitgestellten Container für Podman oder Docker
• Für Sitzung 5 hilfreich, aber nicht erforderlich: ein Coding Agent, mit dem du bereits arbeitest

Das nimmst du mit

• Du schreibst Commits, die erklären, was sich geändert hat und warum, und räumst deine Historie auf, bevor du sie teilst
• Du verstehst, was beim Merge passiert, und vermeidest und löst Konflikte gezielt
• Du wählst ein Entwicklungsmodell, das zu eurem Team und euren Projekten passt, und begründest die Wahl
• Du weißt, was in dein Repository gehört und was in ein Release, und prüfst, was ein Release tatsächlich ausliefert
• Du nutzt Git Worktrees, um parallel an mehreren Aufgaben zu arbeiten und KI-Agenten einzubinden
• Du findest mit git bisect die Änderung, die einen Fehler eingeführt hat, und wertest die Historie deines Projekts aus

Verwandte Schulungen

Diese Schulung ist Teil des Lernpfads Arbeiten mit KI-Agenten.