Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Mit der Einführung von KI-Tools ist die Geschwindigkeit der Code-Generierung rasant gestiegen. Die Review-Geschwindigkeit hält jedoch nicht Schritt. Laut dem DORA-Bericht (DevOps Research and Assessment) aus dem Jahr 2024 ist die durchschnittliche PR-Größe in Teams mit hoher KI-Adoption um 154 % gewachsen, während die Zeit für Code-Reviews um 91 % gestiegen ist. Infolgedessen haben sich die Release-Zyklen sogar verlangsamt. Wenn man jemanden bittet, über 1.000 Zeilen Code auf einmal zu reviewen, ermüdet unweigerlich das Auge. Um diesem Chaos ein Ende zu setzen, müssen wir auf eine strukturierte Kette von Stacked PRs (gestapelten Pull Requests) umstellen.
Wenn man Code einfach blind schneidet, bricht die Kompilierung ab oder Abhängigkeiten gehen kaputt. Es braucht klare Kriterien. Begrenzen Sie einzelne PRs auf maximal 200 geänderte Zeilen und weniger als 10 modifizierte Dateien, damit Reviewer sie in 15 Minuten abschließen können. Eine riesige Funktionalität wird in eine Kette von maximal drei Child-Branches unterteilt:
Diese Reihenfolge wird strikt eingehalten. Fixieren Sie auch das Benennungsschema der Branches im Format feature/<funktionsname>/stack-<schritt>-<beschreibung>.
Der Prozess, einen bereits verhedderten 1.000-Zeilen-Branch (legacy-giant-branch) in eine Kette zu zerlegen, ist unkompliziert.
Aktualisieren Sie zunächst den main-Branch und sichern Sie das Original.
`bash
git checkout main
git pull origin main
git checkout legacy-giant-branch
git branch backup/legacy-giant-branch
`
Erstellen Sie anschließend den Layer-1-Branch von main aus und wenden Sie nur die schemabezogenen Commits per Cherry-Pick an:
`bash
git checkout -b feature/order-refactor/stack-1-schema main
git cherry-pick
git push origin feature/order-refactor/stack-1-schema
`
Nun können Layer 2 und Layer 3 sequenziell auf Basis von Layer 1 aufgebaut werden:
`bash
git checkout -b feature/order-refactor/stack-2-service feature/order-refactor/stack-1-schema
git cherry-pick
git push origin feature/order-refactor/stack-2-service
git checkout -b feature/order-refactor/stack-3-controller feature/order-refactor/stack-2-service
git cherry-pick
git push origin feature/order-refactor/stack-3-controller
`
Auch die Werkzeugwahl ist eine Überlegung wert. Eine reine Git-CLI kostet kein Geld, erfordert aber viel Handarbeit. Spezielle Tools wie Graphite sind bequem, verursachen jedoch Kosten und Infrastrukturabhängigkeiten.
| Evaluierungskriterium | Pure Git CLI | GitHub CLI (gh stack) | Graphite / Externe Tools |
|---|---|---|---|
| Abhängigkeitsverfolgung | Manuelle Branch-Base-Einstellung | Lokales .git & GitHub-Metadaten |
Separates Remote-Engine & lokale DB |
| Rebase-Automatisierung | Manuelle Arbeit pro Branch | Ausführen von gh stack rebase |
Automatische Verarbeitung unterer Ketten bei Commit-Änderungen |
| Lernkurve | Hoch (Verständnis der Git-Prinzipien erforderlich) | Niedrig (Installation der CLI-Erweiterung) | Mittel (Anpassung an separate dedizierte UI erforderlich) |
| Betriebsstabilität | 100 % Standard-Git-kompatibel | Im Public-Preview-Status | Sehr hoch |
Bei der Verwendung von Stacked PRs ist die Aufforderung zur Änderung des Parent-PRs meist der schmerzhafteste Moment. Da sich die Commit-Hashes ändern, werden alle darunterliegenden Child-Branches ungültig. Ein einfacher git rebase führt zu doppelten Commits. Mit der Syntax git rebase --onto muss der zu extrahierende Bereich genau angegeben werden.
Wenn Layer 1 modifiziert wurde, wechseln Sie zu Layer 2 und ordnen den Bereich vom alten Layer-1-Commit-Zeitpunkt bis zum aktuellen HEAD über dem neuen Layer-1-Endpunkt neu an:
`bash
git checkout feature/order-refactor/stack-2-service
git rebase --onto feature/order-refactor/stack-1-schema feature/order-refactor/stack-2-service
git push --force-with-lease
`
Verschieben Sie Layer 3 auf dieselbe Weise über den neuen Layer 2:
`bash
git checkout feature/order-refactor/stack-3-controller
git rebase --onto feature/order-refactor/stack-2-service feature/order-refactor/stack-3-controller
git push --force-with-lease
`
Wenn Sie diesen Vorgang jedes Mal manuell ausführen, passieren zwangsläufig menschliche Fehler. Erstellen Sie ein Shell-Skript, um das sequenzielle Rebase zu automatisieren.
`bash
#!/usr/bin/env bash
set -e
STACK_BRANCHES=(
"feature/order-refactor/stack-1-schema"
"feature/order-refactor/stack-2-service"
"feature/order-refactor/stack-3-controller"
)
TARGET_BASE="main"
git fetch origin
CURRENT_PARENT="$TARGET_BASE"
for BRANCH in "BRANCH"
OLD_BASE=CURRENT_PARENT" "OLD_BASE" ]; then
git rebase --onto "OLD_BASE" "BRANCH"
CURRENT_PARENT="$BRANCH"
done
`
Vergessen Sie nicht, die Funktion zur Aufzeichnung von Konfliktlösungshistorien in den Git-Einstellungen zu aktivieren. Wiederkehrende Konflikte werden dann automatisch übersprungen.
`bash
git config --global rerere.enabled true
git config --global rerere.autoupdate true
git config --global rebase.autoStash true
git config --global rebase.updateRefs true
`
Das Aufteilen eines PRs in drei Teile führt zu dem Problem, dass auch CI-Runner dreimal so oft laufen. Es ist nicht erforderlich, in allen PRs schwere E2E-Tests auszuführen. Konfigurieren Sie die GitHub-Actions-Umgebung so, dass in unteren Layern nur solide Unit-Tests ausgeführt werden und die vollständige Integrationsvalidierung ausschließlich im obersten PR stattfindet.
Fügen Sie eine Bedingung für die Stack-Position in .github/workflows/ci.yml ein:
`yaml
name: Stack-Aware CI Pipeline
on:
pull_request:
branches: [ main ]
jobs:
fast-lint-and-unit-test:
name: Fast Validation (All Layers)
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Linter & Unit Tests
run: |
npm ci
npm run test:unit
heavy-integration-test:
name: Full E2E Test (Top Layer Only)
runs-on: ubuntu-latest
if: |
github.event.pull_request.stack == null ||
github.event.pull_request.stack.position == github.event.pull_request.stack.size
steps:
- uses: actions/checkout@v4
- name: Run Heavy Integration & E2E Tests
run: |
npm ci
npm run test:e2e
`
Die Einrichtung organisationsweiter Branch-Schutzregeln ist ebenfalls unerlässlich:
main landet, während untergeordnete PRs noch nicht gemergt wurden.Damit Stacked PRs ordnungsgemäß funktionieren, müssen Reviewer das Gesamtbild überblicken können. Dokumentieren Sie die Stack-Map in .github/PULL_REQUEST_TEMPLATE.md:
`markdown
Stack Overview
Dieser PR ist Teil der Order-Refactoring-Stack-Kette.
Current Layer Scope
Dependency Status
`
Sobald der untergeordnete PR #101 per Squash-Merge in main integriert wurde, explodiert plötzlich das GitHub-UI-Diff des Child-PRs #102. Dies ist ein Phänomen, bei dem selbst der Code des bereits gemergten PRs #101 als Änderung des Child-PRs erfasst wird. Dies tritt auf, da sich auf dem Git-Commit-Graph die SHA des Squash-Commits von der SHA des Parent-Commits unterscheidet. Geraten Sie nicht in Panik; bringen Sie die Commits des Child-Branches einfach in der folgenden Reihenfolge über main:
`bash
git log --graph --oneline
git checkout feature/order-refactor/stack-2-service
git fetch origin
git rebase --onto origin/main feature/order-refactor/stack-2-service
git push --force-with-lease origin feature/order-refactor/stack-2-service
`
Das Aufteilen eines gigantischen 1,000-Zeilen-PRs ist nicht nur ein Problem der Git-Technik. Es gleicht eher einer Engineering-Aufgabe, die den Code-Review-Prozess und die gesamte Deployment-Kette eines Teams sauber ordnet. Wenn Sie auf einen unordentlichen Legacy-Branch stoßen, erstellen Sie zunächst ein Backup und schneiden Sie ihn in eine 3-Schichten-Struktur auf. Dadurch wird nicht nur die Ermüdung der Reviewer reduziert, sondern Sie erhalten auch selbst eine weitaus klarere Kontrolle über Ihren Code.