--- title: "Dein erstes Projekt: Scaffolding, Dev Server, Git und GitHub" description: "Ein echtes Projekt aufsetzen, lokal im Browser ausführen und sicher unter Versionskontrolle in ein privates GitHub-Repo bringen" type: "lesson" locale: "de-CH" course: "Grundlagen - Von null zur ersten veröffentlichten App" number: "1.6" canonical: "https://agenticschool.dev/de/kurse/foundations/your-first-project-scaffolding-dev-server-git-and-github" datePublished: "2026-06-12" dateModified: "2026-06-12" --- # Dein erstes Projekt: Scaffolding, Dev Server, Git und GitHub - Kurs: Grundlagen - Von null zur ersten veröffentlichten App - Lektion: 1.6 - Dauer: 26 min - Level: einsteiger - Status: published - Kanonische URL: https://agenticschool.dev/de/kurse/foundations/your-first-project-scaffolding-dev-server-git-and-github - Sprache: de-CH > Ein echtes Projekt aufsetzen, lokal im Browser ausführen und sicher unter Versionskontrolle in ein privates GitHub-Repo bringen ## Zusammenfassung Jetzt baust du. Diese Lektion scaffoldet ein echtes Webprojekt mit deinem Agent, startet den Dev Server, sodass du es live im Browser siehst, und bringt alles unter Versionskontrolle mit Git und einem privaten GitHub-Repository - ohne je ein Secret zu committen. Das ist der Moment, in dem deine Idee zu einer laufenden Sache wird. ## Was du lernst - Ein echtes Projekt scaffolden und lokal mit einem Dev Server ausführen (npm run dev) - Die Git-Basics, die zählen: init, commit, und was Versionskontrolle dir wirklich bringt - Sicher in ein privates GitHub-Repo pushen, mit Secrets via .gitignore draussen gehalten ## Überblick Das ist die Lektion, in der das Abstrakte konkret wird. Du scaffoldest ein echtes Projekt, führst es in deinem Browser aus und stellst es unter Versionskontrolle in einem privaten GitHub-Repo. Am Ende hast du eine lokal laufende App und eine sichere, gesicherte Historie deiner Arbeit - das Fundament, auf dem jedes spätere Projekt aufbaut. ## Was du lernst Du scaffoldest ein Projekt mit deinem Agent, startest einen Dev Server und siehst es unter localhost, verstehst, was Git und Commits tatsächlich tun, und pushst deinen Code in ein privates GitHub-Repository mit sicher ausgeschlossenen Secrets. Das sind die alltäglichen Bewegungen des Bauens, also machen wir sie jetzt zur Muskelerinnerung. ## Voraussetzungen Ein funktionierendes Agent-Setup, Node.js und ein GitHub-Account (kostenlos). Die Grundlagen-Seiten zu Git, GitHub, dem Terminal und dazu, was ein Dev Server ist, helfen, falls dir ein Begriff hier neu ist - überflieg sie und komm dann zurück. Du musst keine Git-Befehle auswendig können; der Agent führt die meisten aus, aber du solltest verstehen, was sie tun. ## Das Problem Einsteiger bleiben zwischen "Ich habe eine Idee" und "es läuft auf meinem Bildschirm" stecken. Sie sind unsicher, wie sie ein Projekt starten, haben Angst vor dem Terminal und sind von Git verwirrt. Das Ergebnis ist ein Ordner voller Dateien ohne Historie und ohne Backup, in dem eine schlechte Änderung Stunden Arbeit verliert. Diese Lektion schliesst diese Lücke richtig. ## Schritt für Schritt: scaffolden und ausführen Statt ein Framework auswendig zu lernen, bitte deinen Agent, einen modernen Starter zu scaffolden und jeden Schritt zu erklären. Eine häufige, einsteigerfreundliche Wahl ist ein Vite-basiertes Projekt, aber der genaue Stack zählt weniger als das Verstehen des Ablaufs: Projekt erstellen, Dependencies installieren, Dev Server starten, Browser öffnen. ```bash # Ein neues Vite-Projekt scaffolden (dein Agent kann das für dich ausführen) npm create vite@latest my-first-app # Reingehen und die benötigten Dependencies installieren cd my-first-app npm install # Den lokalen Dev Server starten npm run dev ``` Ein Projekt scaffolden und den Dev Server starten Der Dev Server gibt eine lokale Adresse aus, meist etwas wie http://localhost:5173. Öffne sie in deinem Browser und du siehst deine App auf deinem eigenen Rechner laufen. "localhost" heisst schlicht "dieser Computer" - noch ist nichts im öffentlichen Internet, was beim Bauen genau richtig ist. Bearbeite eine Datei, speichere, und der Browser aktualisiert sich sofort. Diese Live-Schleife lässt Webbauen sich schnell anfühlen. ## Was Git tatsächlich tut Git ist Versionskontrolle: es macht Schnappschüsse deines Projekts namens Commits, damit du immer zurück kannst. Stell es dir als unbegrenzte Rückgängig-Historie mit Etiketten vor. Jeder Commit hält fest, was sich geändert hat und warum, was bedeutet, dass eine schlechte Änderung nie eine Katastrophe ist - du kehrst einfach zum letzten guten Commit zurück. Diese eine Gewohnheit nimmt die Angst weg, die Einsteiger vom Experimentieren abhält, weil nichts, was du tust, endgültig ist, bis du es entscheidest. ```bash # Dieses Projekt mit Git zu tracken beginnen git init # Alle aktuellen Dateien für den ersten Schnappschuss vormerken git add . # Den Schnappschuss mit einer beschreibenden Nachricht speichern git commit -m "Initial project scaffold" ``` Einen Ordner in ein versionskontrolliertes Projekt verwandeln ## Secrets draussen halten, bevor du committest Bevor du je zu GitHub pushst, stell sicher, dass Secrets nicht entkommen können. Eine .gitignore-Datei listet Dinge auf, die Git ignorieren soll. Deine .env-Datei - in der API-Keys leben - und der node_modules-Ordner gehören beide dorthin. Mach das einmal richtig und du veröffentlichst nie versehentlich einen Key. Dein Agent kann diese Datei erstellen, aber du solltest eine korrekte erkennen können. ```bash # .gitignore - sagt Git, was es nie tracken soll node_modules .env .env.local dist ``` Eine minimale .gitignore, die Secrets und Build-Output schützt Die Regel ist absolut: Secrets gehen in .env, .env geht in .gitignore, und der Agent schreibt nie einen Key in committeten Code. Wenn du dir von der Sicherheit aus diesem Kurs sonst nichts merkst, merk dir das. ## Schritt für Schritt: in ein privates GitHub-Repo pushen GitHub speichert dein Repository in der Cloud: ein Backup, eine Historie und später das, womit sich dein Deployment verbindet. Erstelle das Repository als privat, damit dein Business-Code dir gehört. Der Agent kann das meiste davon, aber hier ist, was unter der Haube passiert. ```bash # Ein PRIVATES Repo erstellen und pushen, mit der GitHub CLI gh repo create my-first-app --private --source=. --push # Oder, falls du das Repo zuerst auf github.com erstellt hast: git remote add origin https://github.com/yourname/my-first-app.git git push -u origin main ``` Deinen Code in ein privates GitHub-Repository veröffentlichen Privat ist der Standard, den du für alles Kommerzielle willst. Öffentliche Repos sind grossartig für Open Source, aber dein Business-IP sollte privat starten und nur bewusst öffentlich gehen, nach einem Security-Review - ein Thema, das Kurs 5 ausführlich behandelt. ## Typische Fehler Die schmerzhaften: eine .env-Datei mit einem aktiven API-Key committen (jetzt für immer in deiner Historie, auch wenn du sie später löschst); nie git commit ausführen, sodass es keine Historie zum Zurücksetzen gibt; ein öffentliches Repo für privaten Business-Code erstellen; und am Terminal in Panik geraten, statt den Agent die Befehle ausführen zu lassen, während du liest, was sie tun. Mach langsam, lies jeden Befehl und committe früh und oft. ## Business-ROI Versionskontrolle ist günstige Versicherung mit enormem Nutzen. Ein einziger behebbarer Fehler - eine kaputte Änderung in Sekunden zurücksetzen statt sie stundenlang neu zu bauen - bezahlt die Gewohnheit vielfach. Ein privates Repo schützt das IP, auf dem dein Business steht. Und eine lokal laufende App heisst, dass du schnell iterieren kannst, was der ganze Sinn des Bauens mit Agents ist. ## Checkliste Du bist bereit zu shippen, sobald jedes davon stimmt. Überspring die Secret-Sicherheitspunkte nicht - sie zählen mehr, als sie aussehen. - Dein Projekt läuft lokal und du kannst es unter localhost öffnen. - Das Projekt ist ein Git-Repo mit mindestens einem Commit. - .env steht in .gitignore und enthält in keiner committeten Datei Secrets. - Der Code ist in ein PRIVATES GitHub-Repository gepusht. ## Ressourcen Die Grundlagen-Seiten zu Git, GitHub und dem Dev Server sind deine Referenz, falls ein Schritt wackelig war. Die Claude-Code-Setup-Checkliste in der Ressourcen-Bibliothek hält diese Schutzmassnahmen als wiederverwendbare Liste fest. Ein Schritt bleibt: das hier von deinem Rechner ins öffentliche Internet zu bringen. ## Deine Aufgabe Scaffolde ein kleines Projekt, führ es lokal aus, mach mindestens zwei Commits, während du etwas änderst, und pushe es in ein privates GitHub-Repo mit einer korrekten .gitignore. Bestätige auf github.com, dass deine .env nirgends zu finden ist. Du hast jetzt ein echtes, versionskontrolliertes, gesichertes Projekt. ## Nächste Lektion Deine App läuft auf deinem Rechner. Die letzte Lektion dieses Kurses bringt sie ins öffentliche Internet: Deploy auf Vercel, eine echte Domain verbinden und DNS und Cloudflare handhaben, damit jeder auf der Welt deine Seite besuchen kann. ## Transkript Jetzt baust du. Diese Lektion scaffoldet ein echtes Webprojekt mit deinem Agent, startet den Dev Server, sodass du es live im Browser siehst, und bringt alles unter Versionskontrolle mit Git und einem privaten GitHub-Repository - ohne je ein Secret zu committen. Das ist der Moment, in dem deine Idee zu einer laufenden Sache wird.