From a12730d08ff76f5f4e15c1c7ab2b86b58ed997a3 Mon Sep 17 00:00:00 2001 From: Kai Moritz Date: Sun, 31 May 2026 12:41:06 +0000 Subject: [PATCH] =?utf8?q?CLAUDE.md:=20Historische=20Branches,=20producer?= =?utf8?q?=E2=86=92consumer-Kettendesign=20und=20Effizienz-Prinzip=20dokum?= =?utf8?q?entiert?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Sonnet 4.6 --- CLAUDE.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/CLAUDE.md b/CLAUDE.md index d1303e1d..54f90acb 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -27,6 +27,7 @@ Die Rebase-Elternbeziehungen (ROOTs) sind **ausschließlich** in der ROOT-Tabell > **Diese `CLAUDE.md` ist die einzige maßgebliche Quelle für die Branch-Struktur.** > Vor dem Start einer Aufgabe keine Git-Erkundungsbefehle ausführen (`git branch -a`, `git tag`, `git log --all` o.ä.) — alle benötigten Informationen zur Branch-Hierarchie und den ROOTs sind hier vollständig dokumentiert. +> Nur die in der ROOT-Tabelle aufgeführten Branches werden aktiv gepflegt. Das Repository enthält weitere historische Branches, die nicht mehr gewartet werden und ignoriert werden sollen. ### Branch-Hierarchie (vollständige ROOT-Tabelle) @@ -150,6 +151,7 @@ Zweck dieser Live-Codings: - Sauberes Herunterfahren - Paketierung als Docker-Image - Der benötigte Zusatz-Code und das Setup sollen so einfach wie möglich, aber vollständig funktionsfähig sein +- `grundlagen/simple-consumer` baut absichtlich auf `grundlagen/simple-producer` auf: Beide Übungen verwenden dasselbe Setup und ähnlichen Boilerplate-Code (Konfigurierbarkeit, sauberes Herunterfahren). Der Diff zwischen den beiden Branches zeigt genau, was sich beim Übergang von der Producer- zur Consumer-API ändert — und macht damit den Unterschied für Teilnehmer besonders klar. ### `producer/*` und `consumer/*` @@ -244,10 +246,11 @@ Diese beiden Stellen müssen immer gemeinsam aktualisiert werden — sie halten Beim Einführen von Änderungen in einem Branch wird bewusst darauf geachtet, den Diff gegen den Eltern-Branch so klein wie möglich zu halten. Ziel ist, dass ein Diff zwischen einem späteren Branch und einem seiner Vorfahren **nur zeigt, was der spätere Branch tatsächlich hinzufügt** — kein Rauschen durch unzusammenhängendes Reformatieren oder Umstrukturieren. -Dies ist aus zwei Gründen wesentlich: +Dies ist aus drei Gründen wesentlich: 1. **Überblick**: Der Autor kann immer klar sehen, was ein Branch relativ zu seinem Ursprung ändert. 2. **Lehre**: Der Diff wird direkt in Übungen verwendet — z.B. um Teilnehmern genau zu zeigen, welches Boilerplate verschwindet, wenn Spring Boot oder Spring Kafka Features schrittweise aktiviert werden. +3. **Effizienz**: Verbesserungen müssen nur im frühesten betroffenen Branch eingeführt werden und fließen per Rebase automatisch in alle Downstream-Branches. Dieses Prinzip gilt auch gruppenübergreifend: da `grundlagen/simple-consumer` auf `grundlagen/simple-producer` aufbaut, genügt es, eine Verbesserung einmal im Producer-Branch einzuführen — sie propagiert per Rebase über den Consumer-Branch in alle weiteren Downstream-Branches. **Implikation für Rebases**: Wird eine Verbesserung in einem frühen Branch eingeführt (z.B. Entfernen des `Dockerfile` und überflüssiger Maven-Plugins), müssen alle Downstream-Branches diese Verbesserung konsistent übernehmen. Ein `-- ALIGN`-Commit darf **keine** entfernten Elemente wieder einführen. Er soll nur die branch-spezifischen Änderungen enthalten (z.B. `mainClass` von `ExampleProducer` auf `ExampleConsumer` aktualisieren in der Jib-Konfiguration). -- 2.39.5