Stefan Franke · Daniel Schiffner

Entwicklung interaktiver Softwareanwendungen

Sitzung 4 — Workflow festigen mit VS Code

PH Weingarten

Übersicht

  • Showcase: Das lief richtig gut
  • Zwei Wege heute — heterogene Lerngruppe
  • Stolpersteine aus den letzten Wochen
  • SSH-Schlüssel & Git — wer braucht was?
  • Dokumentation: die README lebt
  • Der neue Workflow: VS Code statt Tab-Chaos
  • Workflow-Training: drei Aufgaben

Das lief richtig gut

isa2.edumake.de ★
Kanban-Board mit Drag & Drop · fetch & API · 21 saubere Commits

isa4.edumake.de
Formular-Validierung · eigene navbar.js · saubere Projektstruktur

isa7.edumake.de
40 Commits in zwei Wochen · Git-Workflow verinnerlicht · Canvas-Effekt

isa9.edumake.de
Slideshow mit eigenem State · eigene nav.js · regelmäßige Commits

Zwei Wege heute

  • Lernstände in der Gruppe sind unterschiedlich — völlig normal
  • Server- und Git-Logs zeigen: Teils ist der Workflow bereits verinnerlicht, teils braucht der Ablauf noch Übung
  • Deshalb heute zwei Wege:

Weg 1: Neues Thema

Für alle, bei denen der Workflow sicher sitzt: Selbstlernpfad Python & Flask — aus der Website wird eine Anwendung. (nächste Folie ↓)

Weg 2: Workflow-Training

Für alle, die den Git-Workflow festigen wollen: Wir vereinfachen den Ablauf mit VS Code und trainieren ihn an JavaScript-Aufgaben.

Ehrliche Selbsteinschätzung: Wer bei pull/push/clone noch nachdenken muss, nimmt Weg 2 — das neue Thema baut auf dem Workflow auf.

Weg 1: Selbstlernpfad Python & Flask

Stolpersteine der letzten Wochen

  • Tab-Chaos: lokales Terminal vs. Server-Terminal
  • SSH-Schlüssel: wer braucht eigentlich welchen?
  • Pull auf dem Server: was kommt da eigentlich an?
  • Browser-Cache: „meine Änderung ist nicht da!“

Tab-Chaos

Zwei Terminal-Tabs — einer lokal, einer auf dem Server. Schnell ist man im falschen Fenster:

  • git push auf dem Server statt lokal → Fehlermeldung
  • nano index.html lokal statt auf dem Server → ändert die falsche Datei
  • Man verliert den Überblick, wo man gerade ist

Lösung heute: Die lokale Seite übernimmt komplett VS Code — mit Klick statt Befehl. Nur für den Server bleibt ein einziges SSH-Terminal.

Tipp zur Orientierung: Der Prompt verrät den Ort — isa05@iss-sose25:~$ = Server, alles andere = euer Laptop.

SSH-Schlüssel: wer braucht welchen?

Forgejo muss beide Geräte kennen, die mit ihm sprechen — euren Laptop und den Server. Jedes Gerät hat sein eigenes Schlüsselpaar; der Public Key wird in Forgejo hinterlegt:

Euer Laptop

eigenes Schlüsselpaar
~/.ssh/id_ed25519

— Public Key →
Forgejo (git.md-phw.de)

Settings → SSH Keys:
2 Einträge — Laptop-Key
+ Server-Key

← Public Key —
Server (edumake.de)

eigenes Schlüsselpaar
~/.ssh/id_ed25519

  • Laptop will push/pull → Forgejo prüft den Laptop-Key
  • Server will pull → Forgejo prüft den Server-Key
  • Fehlt einer der beiden Einträge → Permission denied (publickey)

Pull auf dem Server

Was passiert bei git pull auf dem Server?

  • Es werden nur die Dateien geholt, die ihr lokal geändert und gepusht habt
  • Nichts gepusht → Already up to date. — der Server bekommt nichts
  • Die Ausgabe von git pull zeigt euch genau, welche Dateien sich geändert haben
  • Prüfen: git log --oneline -3 — ist euer letzter Commit angekommen?

Browser-Cache

Alles gepusht, gepullt — und der Browser zeigt trotzdem die alte Seite?

Der Browser speichert HTML, CSS und JS zwischen und liefert euch die alte Version aus dem Cache.

  • Hard Reload:
    • Windows/Linux: Strg + Shift + R
    • macOS: Cmd + Shift + R
  • Alternativ: privates Fenster (ignoriert den Cache)
  • DevTools (F12) → Netzwerk → „Cache deaktivieren“

Merke: Erst Hard Reload — dann Fehler suchen.

Die README lebt

Eure README.md ist kein einmaliges Pflichtdokument — sie ist der Bauplan eures Projekts und wächst mit:

  • Neue Datei oder neuer Ordner? → README aktualisieren (Struktur, Funktion, Verlinkung)
  • Nach jedem push/pull: kurzer Blick ins Forgejo-GUI
    • Stimmt die Verzeichnis- und Dateistruktur mit der README überein?
    • Ist der letzte Commit angekommen?
  • Das GUI ist eure Kontrollinstanz — was dort liegt, ist gesichert

Routine: push → GUI checken → pull auf Server → Browser mit Hard Reload.

Der neue Workflow: VS Code

VS Code hat Git eingebaut (Source Control) — klonen, ändern, committen, pushen und pullen per Klick. Kein lokales Terminal mehr nötig:

VS Code lokal

Dateien bearbeiten
Commit per Klick
Sync = pull + push

Sync ↔
Forgejo git

git.md-phw.de
zentraler Speicher
GUI = Kontrolle

pull →
Server SSH

einziges Terminal
git pull
Website live

Ein Terminal weniger — eine Fehlerquelle weniger.

Farben ab heute

In allen Aufgaben zeigen euch drei Farben, wo ihr gerade arbeitet:

lokal Grün — auf eurem Endgerät, in VS Code
git Gelb — auf Forgejo (git.md-phw.de), im Browser
server Blau — auf dem Server, im SSH-Terminal

Workflow-Training — drei Aufgaben

  1. VS Code & Git einrichten
    u12: Installation, Repo klonen, erster Sync
  2. Workflow-Training I (angeleitet)
    u13: Begrüßung nach Tageszeit — drei komplette Roundtrips
  3. Workflow-Training II (eigenständig)
    u14: Mini-Quiz — mit Pflicht-Zwischenständen
  4. Workflow-Training III (Tandem)
    u15: Zusammenarbeit im Ping-Pong — Feinschliff, Merge-Konflikt, README

Für die Schnellen: Selbstlernpfad Python & Flask (pres/5.html) · Aufgaben: u8: Flask-Einführung · u9: Flask & Datenbanken

Heute geschafft?

  • VS Code eingerichtet, Repo geklont ✓
  • Erster Commit + Sync aus VS Code ✓
  • Mindestens drei komplette Roundtrips ✓
  • README aktuell & GUI-Abgleich gemacht ✓

Nächstes Mal: Python & Flask für alle — aus der Website wird eine Anwendung.