From 88e588d2247e4d44483530ca2de71f2449baa33c Mon Sep 17 00:00:00 2001
From: Kai Moritz <kai.milan.moritz@googlemail.com>
Date: Fri, 29 May 2026 18:09:17 +0000
Subject: [PATCH] CLAUDE.md: Rebase-Ansatz auf `git rebase -i` umgestellt;
 ROOT-Ermittlung dokumentiert
MIME-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit

- Rebase-Strategie von manuellem Cherry-Pick auf `git rebase -i` umgestellt
- Dokumentiert, wie der ROOT eines Branches über BRANCHES.sh nachgeschlagen wird
- Erklärt den Umgang mit Konflikten beim interaktiven Rebase

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
---
 CLAUDE.md | 38 +++++++++++++++++++++++++++-----------
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/CLAUDE.md b/CLAUDE.md
index 8d0474c1..991c359e 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -234,34 +234,50 @@ Branches enthalten kein `Dockerfile`, keine `.dockerignore` und keine `.maven-do
 
 Image-Name muss immer `juplo/<artifactId>:<version>` (Maven) oder `juplo/${project.name}:${project.version}` (Gradle) entsprechen.
 
-### Rebase-Strategie nach Branch-Typ
+### ROOT eines Branches ermitteln
 
-Alle Rebases folgen dem `git checkout -B <branch> <ROOT>--claude-N` + `git cherry-pick <commits>`-Muster statt `git rebase`, weil Konflikte die Norm sind. Die eindeutigen Commits ermitteln:
+Der ROOT jedes Branches ist in `BRANCHES.sh` (auf dem `scripting`-Branch) als `<variable>__ROOT`-Variable definiert. **Vor jedem Rebase** den ROOT nachschlagen:
 
 ```bash
-git log --oneline --reverse <branch>--claude-N ^<ROOT>--claude-N
+git checkout scripting
+grep "^<variante>__ROOT" BRANCHES.sh
+# oder: alle ROOTs auflisten
+grep "__ROOT=" BRANCHES.sh
 ```
 
-**Standard-Lösungs-Branches:**
+Alternativ lässt sich der ROOT auch aus dem `--claude-N`-Tag ableiten:
 ```bash
-git checkout -B <branch> <ROOT>--claude-N
-git cherry-pick <commit1> <commit2> ...
-git tag <branch>--claude-N
+git log --oneline -3 <branch>--claude-N
+# Die letzten Commits zeigen, welcher Eltern-Branch vorausgeht
 ```
 
-**`--vorlage`-Branches** (ROOT = der entsprechende Lösungs-Branch, bereits rebasiert):
+### Rebase-Strategie nach Branch-Typ
+
+Alle Rebases erfolgen mit `git rebase -i <ROOT>--claude-N`, nachdem der Branch auf den neuen Stand des ROOT zurückgesetzt wurde:
+
 ```bash
 git checkout -B <branch> <ROOT>--claude-N
-git cherry-pick <einzelner-vorlage-commit>
+git rebase -i <ROOT>--claude-N  # oder: git rebase -i HEAD  (da HEAD = ROOT)
+```
+
+Im interaktiven Editor zeigt Git alle Commits des Branches. Im Normalfall werden alle Commits mit `pick` übernommen. Bei Konflikten:
+- Konflikt lösen, `git add` der gelösten Dateien, dann `git rebase --continue`
+- `git rebase --abort` wenn die Situation unklar ist — danach neu analysieren und mit neuem `git rebase -i` fortfahren
+
+```bash
 git tag <branch>--claude-N
 ```
+
+**Hinweis:** Im Gegensatz zu `git cherry-pick` mit manuell gesammelten Commit-Hashes erkennt `git rebase -i` automatisch alle Commits des Branches. Commits können direkt im Editor mit `drop` entfernt oder mit `edit` zur Nachbearbeitung markiert werden.
+
+**`--vorlage`-Branches** (ROOT = der entsprechende Lösungs-Branch, bereits rebasiert):
 Vorlage-Commits löschen typischerweise `README.sh`, vereinfachen Java-Dateien (entfernen Callbacks) oder löschen Build-Dateien bei reinen Infrastruktur-Setups. Diese Löschungen sind intentional.
 
 **`--livecoding--schritte`-Branches:**
-Wie Vorlage, aber alle Schritt-Commits in Reihenfolge cherry-picken. Besondere Regeln siehe Abschnitt "Live-Codings".
+Alle Schritt-Commits in Reihenfolge übernehmen. Besondere Regeln siehe Abschnitt "Live-Codings".
 
 **Reine Infrastruktur-Branches** (kein Java-Quellcode, keine Build-Dateien):
-Der Cherry-Pick löscht korrekt `pom.xml`, `build.gradle`, `src/` usw. Diese Löschungen sind intentional.
+Der Rebase löscht korrekt `pom.xml`, `build.gradle`, `src/` usw. Diese Löschungen sind intentional.
 
 ### Wiederkehrende Konfliktmuster
 
-- 
2.39.5