Beispielarbeiten · Software & Web-Apps

Git-Workflow: Branch-Strategie, Worktree-Skript und Pull-Request-Vorlage

Für parallele Entwicklung: eine Branch-Strategie, ein Skript für getrennte Arbeitsordner und eine Vorlage für Pull Requests. Das Skript läuft in einem Wegwerf-Repository, getrennte Branches und sicheres Aufräumen sind gemessen.

Musterarbeit (Demo), kein Kundenauftrag. Gebaut als Probeaufgabe mit erfundenen Beispieldaten; die Prüfzahlen unten stammen aus dem automatischen Prüflauf und sind nicht geschönt.

Was gebaut wurde

Branch-Strategie mit Regeln für Zusammenführen und Freigabe
Worktree-Skript im Wegwerf-Repository ausgeführt
Vorlage für Pull Requests
Repository erfunden

pull_request_template.md herunterladen wt.sh herunterladen

Wie geprüft wurde

Automatischer Prüflauf vom 29.10.2026, aus dem Protokoll (Testdaten erfunden, Zahlen gemessen):

Demo: Branch-Strategie, Worktree-Skript im Wegwerf-Repo ausgefuehrt (2 Worktrees, getrennte Branches, Aufraeumen sicher), PR-Vorlage
17 Pruefungen, Gegenprobe faellt durch

Grenzen

Was diese Probe nicht abdeckt, steht hier, damit niemand mehr erwartet:

Schutzregeln fuer main setzt der Kunde im Hosting-Dienst; wir liefern die Liste
Das Skript braucht eine POSIX-Shell (Linux, macOS, Git Bash) und Git ab Version 2.17
Eine bestehende Historie wird nicht umgeschrieben ohne ausdrueckliche Absprache

Der Workflow

# Git-Workflow - Demo-Projekt Kornblume-Shop (erfunden)

Musterarbeit von GL Tools. Projekt und Namen sind erfunden.

## 1. Branch-Strategie

- `main` ist immer auslieferbar. Direkt darauf wird nicht committet; Aenderungen kommen nur ueber einen Pull Request.
- Arbeit entsteht auf kurzen Branches von `main`: `feature/<name>`, `fix/<name>`, `docs/<name>`. Lebensdauer wenige Tage.
- Commit-Nachrichten nach Conventional Commits (`feat(cart): ...`, `fix(auth): ...`), damit der Changelog sich selbst schreibt.
- Zusammenfuehren per Squash-Merge, wenn der Branch aus vielen kleinen Commits besteht; sonst Rebase und Fast-Forward.
- Releases werden mit einem Tag `vX.Y.Z` auf `main` markiert; Hotfixes entstehen von diesem Tag aus als `fix/<name>`.

## 2. Worktrees: mehrere Aufgaben gleichzeitig

Ein Worktree ist ein zweiter Arbeitsordner desselben Repositorys mit eigenem Branch. So bleibt die laufende Arbeit unberuehrt,
wenn eine Fehlerbehebung dazwischenkommt, ohne `stash` und ohne zweiten Klon.

```
./wt.sh neu rabattfeld      # legt ../<repo>-wt/rabattfeld auf feature/rabattfeld an
./wt.sh liste               # zeigt alle Worktrees
./wt.sh weg rabattfeld      # entfernt Ordner und gemergten Branch
```
Regeln: ein Branch gehoert zu genau einem Worktree; ungesicherte Aenderungen werden nie automatisch verworfen; ein nicht
gemergter Branch bleibt beim Aufraeumen erhalten.

## 3. Pull-Request-Vorlage

Datei `.github/pull_request_template.md`:
```
## Was aendert sich?
<EIN SATZ>

## Warum?
<TICKET-LINK ODER BEGRUENDUNG>

## Wie wurde es geprueft?
- [ ] Tests laufen lokal
- [ ] Manuell geprueft: <WAS>

## Risiko und Rueckweg
<WAS KANN SCHIEFGEHEN, WIE WIRD ZURUECKGEROLLT>

## Checkliste
- [ ] Keine Zugangsdaten oder .env im Diff
- [ ] Changelog-tauglicher Titel (feat/fix/...)
```

## 4. Schutz fuer main

Erforderlich: Pull Request, mindestens eine Freigabe, gruene Tests, kein Force-Push. Diese Einstellungen setzt der Kunde im
Hosting-Dienst selbst; wir liefern die Liste.

So etwas für deinen Betrieb?

Beschreib kurz, was du brauchst. Du bekommst einen Festpreis, bevor ich anfange; ohne dein Ja passiert nichts.

Zur Werkstatt