Folge 022: KI-Änderungen prüfen, PR reviewen, Features im Blick

Der Agent hat wieder Dateien angefasst. Die Frage ist nicht „Hat er was gemacht?“, sondern passt das zu deinem Projekt? Dafür brauchst du keine Git-Befehlszeile, wenn du nicht willst: Cursor und GitHub zeigen dir Diffs und Listen. Diese Folge ordnet lokal committen, Pull Request lesen, Code Review und Live-Deployments ein. Große PRs mit Preview: Folge 016. Push-Regel: Folge 001, Folge 006.

Was wurde geändert? (Cursor)

In der IDE links Explorer (Dateien), daneben „Source Control“ (Quellcode-Verwaltung). Dort siehst du geänderte Dateien, z. B. .gitignore mit dem genauen Zusatz. Optional: pro Datei Timeline (Zeitachse) für die Historie dieser einen Datei (welcher Commit wann). Die kleine Outline neben dem Code ist eher für Funktionen im File, für Git-Überblick reicht meist Source Control.

Die Commit-Grafik zeigt Zweige und wo dein Stand zu origin (Server) steht. Du kannst Zeilen lesen, was der Agent eingefügt hat, und nur die Dateien stagen, die in den nächsten Commit sollen. Dann „Commit“ (Commit erstellen): der Stand ist noch lokal. „Sync Changes“ (Änderungen synchronisieren) bzw. „Pull“ (Pull) holt Remote-Änderungen, „Push“ (Push) schickt deine Commits zu GitHub (nur wenn du es willst).

Pull Request mit vielen Commits

Ein zweiter Agent liefert oft einen eigenen Branch und einen Pull Request mit mehreren Commits (in der Session waren es neun Stück, weil du mehrfach nachgebessert hast). Auf GitHub im PR:

• „Files changed“ (Geänderte Dateien): welche Pfade, Zeile für Zeile Diff.
• Unter .cursor/rules/ liegen Anweisungen nur für Agenten, nicht für Besucher der Website.
• Unter docs/ steckt Redaktions- und Entwickler-Doku (Meta, nicht der öffentliche Seitentext).
• Unter scripts/ hängen deterministische Checks, z. B. check-content-links.py (Links und Embeds) und check-content-no-video-hints.py (Artikel ohne Screencast-Meta-Hinweise). Im PR siehst du „All checks have passed“, wenn CI grün ist.
• Die korrigierten Folgen liegen unter src/content/articles/ (je Folge ein Ordner mit index.md). Die Features-Seite unter /features/ liegt nicht dort, sondern in src/content/pages/features/index.md (Collection pages, siehe Folge 004).

Du musst nicht alle 21+ Artikel komplett neu lesen: konzentrier dich auf geänderte Dateien und den Diff. Willst du den Ton einer Zeile ändern, nutze auf GitHub „Suggest changes“ (Änderung vorschlagen) an der Zeile, sammle mehrere Vorschläge, dann „Start review“ (Review starten) und am Ende „Submit review“ (Review absenden). So landet z. B. eine präzisere Rollback-Formulierung in Folge 012 im Branch des PR, bevor du mergst.

Rollback in Cloudflare (nochmal klar)

In Folge 012 ging es um Preview und Production. In der Deployments-Liste ist blau markiert, was gerade live ist; ein Build in Arbeit kannst du noch nicht zurückdrehen. Preview-Deployments sind andere Zweige, du machst sie nicht per Rollback zur Live-Site.

Für Production gilt laut Cloudflare Pages Rollbacks: Projekt → „Workers & Pages“ (Workers und Pages) → dein Pages-Projekt → „Deployments“ (Bereitstellungen) → bei einem älteren erfolgreichen Production-Deployment das Dreipunkte-Menü (⋯) → „Rollback to this deployment“ (Auf dieses Deployment zurücksetzen). Nicht in einer Detail-Ansicht suchen, wo kein Rollback-Button steht: die Aktion sitzt an der Liste.

Merge, Live und Qualität

Wenn du den PR akzeptierst (Merge, siehe Folge 016), baut Cloudflare main neu. Du musst im PR nicht selbst committen: sag dem Agenten „nimm den Stand, korrigiere Zeile X, starte Review“ oder starte einen neuen Chat für Quality Check („Passt das zum Konzept?“).

Push nicht automatisch durch den Agenten laufen lassen (Folge 001). Lieber explizit: committen ja, pushen nur auf Anweisung.

Feature-Stand und Site

Damit du (oder Fork-Nutzer) sehen, was die Site schon kann: Features auf hautoo und die Kurzliste im README. Neu dazu gekommen u. a.:

• Konfiguration im CMS (Collection config, Datei src/content/config/site.yaml): Design (z. B. Sticky Header, Höhen pro Mobil/Tablet/Desktop) und Content (globales Inhaltsverzeichnis, pro Seite/Artikel überschreibbar).
• Features-Seite live unter /features/, Quelle im Repo: src/content/pages/features/index.md.
• Suche im Header (Glossar und Inhalte finden, z. B. „Was ist CSS?“).
• Angepasstes Logo mit Pfad-Animation und Transparenz-Effekt (Tablet/Mobil mitgedacht).

Wenn du nur Inhalte und Farben tauschen willst: Fork und eigene Texte (Folge 020). Bilder schlank halten: Folge 021.

Kurz merken

• Source Control + Files changed = deine Kontrolle vor Live.
• Checks im PR fangen Grobfehler ab, ersetzen kein Lesen der Diffs.
• Rollback nur über Production-Deployments und Dreipunkte-Menü.
• Features-Seite + README = Überblick ohne Code lesen.