CLAUDE.md: Rebase-Mechanik erklärt (git log zwischen Sessions), Spring-Boot-Version...

diff --git a/CLAUDE.md b/CLAUDE.md
index b66b0d6f5e521452ee965c8e2c8475030c81195c..2d29b96451076b7c1d9a6721fcdab78dbeff7138 100644 (file)
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -172,7 +172,7 @@ Ein typischer Übungs-Branch enthält:
 
 - `README.sh` — die kanonische Art, die Übung auszuführen (baut, startet Docker Compose, führt Demo aus)
 - `docker/docker-compose.yml` — lokales Kafka-Cluster-Setup
-- `pom.xml` und/oder `build.gradle` — Maven/Gradle-Build (Java 21, Spring Boot 4.0.2)
+- `pom.xml` und/oder `build.gradle` — Maven/Gradle-Build (Java 21, Spring Boot 4.0.6)
 - `src/` — Java-Quellcode (Gruppe `de.juplo.kafka`)
 
 Einige Branches enthalten **nur** eine `docker/docker-compose.yml` ohne Build-Dateien oder Quellcode. Dies sind reine Infrastruktur-Setups für Übungen, in denen Teilnehmer mit Kafka-Clients aus einer vorherigen Übung weiterexperimentieren.
@@ -400,6 +400,14 @@ Wandelt ein Branch die Anwendung in eine **reine Java-Bibliothek** um (keine Spr
 - **`pom.xml`**: `spring-boot-maven-plugin`-Plugin-Block entfernen
 - **`build.gradle`**: Plugin `id 'com.gorylenko.gradle-git-properties'`, Block `springBoot { buildInfo() }` und Block `bootBuildImage { }` entfernen
 
+### Interpretation von `git log` zwischen Sessions
+
+Ein Rebase schreibt alle Commit-Hashes im Branch neu — auch wenn der Inhalt eines Commits identisch bleibt, ändert sich sein Hash, weil sich sein Parent-Commit geändert hat. Daher gilt:
+
+`git log <branch>--claude-N ^<branch>--claude-(N-1)` zeigt nach einer Session **mehr Commits als tatsächlich inhaltlich neu** sind. Beispiel: Bekommt `grundlagen/docker` einen neuen Commit (z.B. Kafka-Image-Update) und wird anschließend `grundlagen/simple-producer` darauf rebasiert, erscheinen im Vergleich `--claude-N ^--claude-(N-1)` für `simple-producer` **alle** seine Commits als „neu" — obwohl nur der eine Commit aus `grundlagen/docker` (kaskadiert durch den Rebase) plus ggf. ein direkt im Branch hinzugefügter Commit (z.B. Spring-Boot-Update) wirklich neuen Inhalt tragen. Alle anderen Commits waren inhaltlich schon vorher vorhanden, haben aber durch den Rebase neue Hashes bekommen.
+
+Um die wirklich neuen Inhalte einer Session zu identifizieren, nicht die Anzahl der Commits zählen, sondern die Commit-**Beschreibungen** vergleichen: Commits mit unveränderter Beschreibung tragen keinen neuen Inhalt — sie wurden nur durch den Rebase umgehashed.
+
 ### Session-Tagging-Schema
 
 Jede Rebase-Session taggt jeden abgeschlossenen Branch als `<branch>--claude-N`. Die Tag-Nummer erhöht sich pro Session. Tags dienen als Wiederherstellungspunkte — `./RESET.sh claude-N` setzt alle Branches auf die entsprechenden Tags zurück. Immer direkt nach Abschluss eines Branches taggen, bevor mit dem nächsten begonnen wird.