Git/GitHub-Workflow dieses Projekts

Dokumentiert den tatsaechlich verwendeten git/gh-Workflow - vom lokalen Repo bis zum gemergten Pull Request. Nachtraeglich erstellt (offener Punkt aus der Jenkins-Pipeline-Arbeit), anhand des realen Verlaufs in diesem Repository.

1. Feature-Branch anlegen

git checkout -b feature/jenkins-multi-stage-pipeline

Jede groessere, in sich abgeschlossene Arbeitseinheit (Jenkins-Pipeline, jetzt die Spring/Jakarta/OpenShift-Migration) bekommt einen eigenen Feature-Branch von master aus, niemals direkte Commits auf master.

2. Arbeiten, in thematischen Commits

Durchgehende Konvention in diesem Projekt: 2-3 inhaltlich abgegrenzte Commits pro Phase/ Feature, jeweils mit sprechendem Praefix (Phase N (x/y): ..., Jenkins-Pipeline (x/y): ...). Kein git commit -m "wip" oder aehnliches - jeder Commit soll fuer sich lesbar sein.

git add <konkrete Dateien>   # nie git add -A, um versehentliches Mitcommitten zu vermeiden
git commit -m "$(cat <<'EOF'
Jenkins-Pipeline (1/2): Jenkinsfile + Deploy-Simulation + Stage-Configs

Kurze Begruendung des WARUM, nicht nur des WAS.
EOF
)"

3. Privates GitHub-Repository anlegen

gh repo create nursude/novaris-versicherung-legacy --private --source=. --remote=origin

Bewusst privates Repo (Nutzerentscheidung) - dieses Lernprojekt enthaelt keine echten Geheimnisse, aber auch keinen Grund fuer oeffentliche Sichtbarkeit.

4. Branch pushen

git push -u origin feature/jenkins-multi-stage-pipeline

-u setzt das Remote-Tracking, damit spaetere git push/git pull ohne weitere Angaben funktionieren.

5. Pull Request erstellen

gh pr create --title "Jenkins Multi-Stage-Pipeline (local/test/QS/prod)" --body "$(cat <<'EOF'
## Summary
- <Kernpunkte der Aenderung als Bulletpoints>

## Test plan
- [ ] <konkrete Verifikationsschritte>

Generated with Claude Code
EOF
)"

gh pr create erkennt Base- (master) und Head-Branch automatisch aus dem aktuellen Checkout; --body per Heredoc vermeidet Escaping-Probleme mit Zeilenumbruechen.

6. Pull Request reviewen

gh pr view <NR> --json title,body,author,baseRefName,headRefName,state,additions,deletions,changedFiles,labels
gh pr diff <NR>

Das Review lief hier als Selbstreview auf dem eigenen Diff (kein zweites Teammitglied verfuegbar) - fand zwei echte Probleme (nicht ausfuehrbares deploy.sh, ungenutzte injizierte Credentials), die vor dem Merge noch behoben wurden (Review-Fixes: ausfuehrbares deploy.sh + echte Credential-Verifikation).

7. Pull Request mergen

gh pr merge <NR> --merge --delete-branch

--delete-branch raeumt den Feature-Branch remote und lokal auf, sobald der Merge steht - verhindert, dass abgeschlossene Branches sich ansammeln. Ergebnis in diesem Projekt: PR #1 (feature/jenkins-multi-stage-pipeline -> master), gemerged am 2026-08-07, https://github.com/nursude/novaris-versicherung-legacy/pull/1.

Zusammengefasster Ablauf

git checkout -b feature/...
# ... Commits ...
gh repo create ... --private --source=. --remote=origin   # nur beim allerersten Mal
git push -u origin feature/...
gh pr create --title ... --body ...
gh pr view <NR> --json ...   /   gh pr diff <NR>            # Review
git push origin feature/...                                  # Review-Fixes, falls noetig
gh pr merge <NR> --merge --delete-branch

Dieser Ablauf gilt unveraendert auch fuer den aktuellen Migrations-Branch (feature/spring-jakarta-openshift-migration).

⌂ Cockpit