Infografik

3 Wege zur eigenen Website mit GitHub Pages

Vom einfachen Text bis zum App-Projekt – jeder Weg Schritt für Schritt erklärt, auch ohne Programmierkenntnisse.

Welcher Weg passt zu mir?
🤔 Ich möchte eine Website auf GitHub Pages veröffentlichen
Was habe ich bzw. was möchte ich nutzen?
Nur Text & Bilder
Eigene HTML-Datei
Lovable / Vite / React
Was passiert bei «Commit Changes»?
Dieser Button taucht in allen drei Wegen auf – hier wird erklärt, was er genau macht.
💾

Commit = Speichern + Protokollieren

Mehr als nur «Speichern» – ein dauerhafter Eintrag in die Geschichte deines Projekts
Wenn du auf GitHub eine Datei erstellst, bearbeitest oder hochlädst, erscheint der grüne Button «Commit changes». Das ist nicht dasselbe wie «Speichern» auf deinem Computer. Ein Commit erstellt einen unveränderlichen Snapshot deines gesamten Projekts – mit Zeitstempel, Beschreibung und deinem Namen. Wie ein Eintrag in einem Logbuch, den du jederzeit nachschlagen oder rückgängig machen kannst.
🎮

Analogie: Stell dir Commits wie Checkpoints in einem Videospiel vor. Jeder Checkpoint speichert den gesamten Spielstand zu diesem Zeitpunkt. Du kannst jederzeit zu jedem früheren Checkpoint zurückkehren, wenn etwas schiefgeht. Und du hast eine komplette Liste aller Checkpoints mit Beschreibung, wann und warum du sie gesetzt hast.

Was passiert in welcher Reihenfolge?

📸

1. Snapshot erstellen

Git macht ein «Foto» vom aktuellen Zustand aller Dateien im Repository – nicht nur der geänderten Datei. So ist immer klar, wie das gesamte Projekt zu diesem Zeitpunkt aussah.

Passiert automatisch
📝

2. Logbuch-Eintrag schreiben

Der Snapshot bekommt eine eindeutige ID (z.B. a3f8b2c), deine Commit-Nachricht (z.B. «Startseite hinzugefügt»), deinen Namen und einen Zeitstempel. Das ist der eigentliche «Commit» – der Eintrag in die Versionsgeschichte.

Du gibst die Nachricht ein
🚀

3. Auf den Server schreiben (Push)

Wenn du direkt auf github.com arbeitest, wird der Commit sofort auf den Server geschrieben. Bei lokaler Arbeit mit Git sind «Commit» und «Push» zwei getrennte Schritte – auf der Website passiert beides in einem Klick.

Auf github.com automatisch

4. GitHub Pages reagiert

GitHub erkennt, dass sich etwas auf dem konfigurierten Branch geändert hat und startet automatisch den Veröffentlichungsprozess. Je nach Weg: Jekyll baut Markdown um, HTML wird direkt übernommen, oder der Actions-Workflow startet.

Passiert automatisch

So sieht der Ablauf aus – der Commit ist das Bindeglied

✏️
Datei
bearbeiten
💾
Commit
Changes
📦
Snapshot
+ Logbuch
🚀
Push auf
Server
🔄
Build
Prozess
🌍
Website
live!

📍 Wo und wann klickst du «Commit Changes»?

Neue Datei erstellen
Add file → Create new file
Du schreibst Inhalt direkt im Browser (z.B. index.md oder _config.yml). Unten auf der Seite gibst du eine Commit-Nachricht ein und klickst «Commit changes».
Datei hochladen
Add file → Upload files
Du lädst eine oder mehrere Dateien hoch (z.B. index.html, Bilder, CSS). Nach dem Drag & Drop klickst du unten auf «Commit changes».
Datei bearbeiten
Datei öffnen → Stift-Symbol ✏️
Du öffnest eine bestehende Datei im Repo, klickst auf den Stift zum Bearbeiten, machst deine Änderungen, und klickst oben rechts «Commit changes».
Aus Lovable pushen
Lovable → GitHub Sync
Lovable erstellt den Commit automatisch, wenn du Änderungen an deinem Projekt synchronisierst. Du siehst den Commit danach im Repository unter dem Tab «Commits».
github.com/user/meine-seite/new/main
Commit message *
Startseite hinzugefügt
Extended description (optional)
index.html mit Grundstruktur und Navigation erstellt
Commit directly to the main branch
✓ Commit changes
⚙️

Was passiert danach? Der «pages-build-deployment» Workflow

Sichtbar im Tab «Actions» deines Repositorys

Sobald dein Commit auf dem main-Branch gespeichert ist, erkennt GitHub automatisch die Änderung und startet den Workflow «pages-build-deployment». Du musst nichts tun – alles läuft im Hintergrund. Im Tab Actions kannst du den Fortschritt live mitverfolgen:

📥
1. Dateien einsammeln

GitHub nimmt den aktuellen Stand aller Dateien aus dem main-Branch.

🔍
2. Prüfen & Bauen

Bei Markdown-Seiten wandelt Jekyll den Text in HTML um. Bei reinem HTML wird nur geprüft, ob eine index.html vorhanden ist. Bei Vite/React wird npm run build ausgeführt.

📦
3. Artefakt erstellen

Die fertigen Dateien werden als Paket zusammengeschnürt – das sogenannte «Build-Artefakt».

🌍
4. Auf CDN verteilen

Das Paket wird auf GitHubs weltweites Content Delivery Network hochgeladen. Die Seite ist jetzt unter username.github.io/repo erreichbar – mit HTTPS.

Im Tab «Actions» siehst du für jeden Commit einen Eintrag. Der Status zeigt dir, ob alles geklappt hat:

✅ Erfolgreich
Seite ist live und aktualisiert
🟡 In Progress
Wird gerade gebaut (30–90 Sek.)
❌ Fehlgeschlagen
Klick drauf → Log zeigt Fehler
📖 Weiter: Die drei Wege im Detail → ↑ Nach oben
Die drei Wege im Detail
Jeder Weg wird Schritt für Schritt erklärt – mit Beispielen, die du direkt nachmachen kannst.
📝

Weg 1: Markdown

Einfacher Text wird automatisch zur Website
Schwierigkeit
Was ist das? Du schreibst ganz normalen Text mit ein paar einfachen Zeichen für Überschriften, fetten Text und Links. GitHub verwandelt das automatisch in eine hübsche Webseite – du brauchst keinerlei Programmierkenntnisse. Ideal für Dokumentationen, Blogs, persönliche Seiten oder Projektbeschreibungen.
1

Repository auf GitHub erstellen

Gehe auf github.com, klicke oben rechts auf «+»«New repository». Gib einen Namen ein (z.B. meine-seite), wähle Public und aktiviere «Add a README file». Klicke auf «Create repository».

github.com/new
Repo name:
meine-seite
Visibility:
◉ Public
Initialize:
☑ Add a README file
Create repository
2

Markdown-Datei erstellen

Im Repository klickst du auf «Add file»«Create new file». Nenne die Datei index.md. Das ist deine Startseite. Schreibe deinen Inhalt mit Markdown-Formatierung:

index.md
# Willkommen auf meiner Seite

Das ist meine erste Website auf GitHub Pages! 🎉

## Über mich

Ich heisse Stefan und arbeite als **Product Owner**.
In meiner Freizeit fotografiere ich gerne.

## Meine Projekte

- [Projekt A](https://example.com)
- [Projekt B](https://example.com)

![Mein Foto](bild.jpg)

Unten auf der Seite klickst du dann «Commit changes», um die Datei zu speichern.

💾 Was passiert bei «Commit changes»? →
3

GitHub Pages aktivieren

Gehe zu SettingsPages (linke Seitenleiste). Wähle bei «Source» den Branch main und den Ordner / (root). Klicke auf Save. Nach 1–2 Minuten ist deine Seite live!

github.com/user/meine-seite/settings/pages
Source:
Deploy from a branch
Branch:
main
/ (root)
Save
4

Optional: Theme wählen mit _config.yml

Erstelle eine Datei _config.yml im Repository, um ein schönes Design zu aktivieren – ohne eine Zeile CSS zu schreiben:

_config.yml
theme: minima
title: Meine Website
description: Meine persönliche Seite
🌐

Weg 2: HTML-Datei

Fertige Webseite direkt hochladen
Schwierigkeit
Was ist das? Du hast eine fertige HTML-Datei (z.B. selbst erstellt, von einem Tool generiert, oder von Claude erstellt). Du lädst diese Datei einfach auf GitHub hoch – und sie wird genau so angezeigt, wie sie ist. Du hast volle Kontrolle über das Design. Kein automatischer Build nötig.
1

Repository erstellen

Wie bei Weg 1: Neues Repository auf GitHub erstellen. Name frei wählbar, z.B. portfolio. Public wählen.

2

HTML-Datei hochladen

Klicke auf «Add file»«Upload files». Lade deine index.html hoch (plus allfällige CSS, JS, Bilddateien). Dann auf «Commit changes» klicken.

💾 Was passiert bei «Commit changes»? →
index.html – Beispiel
<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="UTF-8">
  <title>Mein Portfolio</title>
  <style>
    body { font-family: sans-serif; max-width: 800px; margin: 0 auto; }
    h1 { color: #2d5be3; }
  </style>
</head>
<body>
  <h1>Willkommen!</h1>
  <p>Das ist meine Website.</p>
  <img src="foto.jpg" alt="Mein Bild">
</body>
</html>
3

GitHub Pages aktivieren

Gleich wie bei Weg 1: Settings → Pages → Branch: main, Ordner: / (root) → Save. Die Seite wird direkt so angezeigt, wie dein HTML aussieht.

4

Änderungen machen

Jedes Mal, wenn du eine Datei im Repository änderst oder neu hochlädst, wird die Seite automatisch nach 1–2 Minuten aktualisiert. Keine weiteren Schritte nötig.

Weg 3: Lovable / Vite / React

App-Projekte automatisch bauen und veröffentlichen
Schwierigkeit
Was ist das? Lovable erstellt ein vollständiges App-Projekt (React + Vite). Dieses kann nicht einfach als HTML hochgeladen werden – es muss zuerst «gebaut» werden. Ein GitHub Actions Workflow erledigt das automatisch: bei jedem Push wird die App kompiliert und das Ergebnis veröffentlicht. Klingt kompliziert, ist aber einmal eingerichtet ein Selbstläufer.
1

Lovable verbindet sich mit GitHub

Lovable erstellt automatisch ein GitHub-Repository, wenn du dein Projekt mit GitHub verbindest (Button «GitHub» in Lovable). Das Repo enthält den gesamten Quellcode deines Projekts.

2

Pages-Quelle auf «GitHub Actions» stellen

Im Repository: Settings → Pages. Wichtig: Wähle hier nicht «Deploy from a branch», sondern «GitHub Actions» als Source. Das ist der Unterschied zu Weg 1 und 2!

github.com/user/lovable-app/settings/pages
Source:
GitHub Actions
⚠️ Nicht «Deploy from a branch» – die App muss zuerst gebaut werden!
3

Workflow-Datei erstellen

Erstelle im Repository die Datei .github/workflows/deploy.yml. Das ist das «Rezept», das GitHub sagt, wie die App gebaut werden soll. Klicke auf «Add file» → «Create new file» und gib den Pfad ein:

.github/workflows/deploy.yml
name: Deploy to GitHub Pages
on:
  push:
    branches: [main]

permissions: # Rechte für den Workflow
  contents: read
  pages: write
  id-token: write

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    environment:
      name: github-pages
    steps:
      - uses: actions/checkout@v4 # Code holen
      - uses: actions/setup-node@v4 # Node.js bereitstellen
        with: { node-version: 20 }
      - run: npm ci # Pakete installieren
      - run: npm run build # App bauen → dist/
      - uses: actions/upload-pages-artifact@v3
        with: { path: dist } # Ergebnis hochladen
      - uses: actions/deploy-pages@v4 # Veröffentlichen
4

Base-Path in vite.config.ts setzen

Damit Bilder, CSS und JavaScript auf der veröffentlichten Seite gefunden werden, muss der Repository-Name als Basispfad gesetzt werden. Öffne vite.config.ts und ergänze die base-Zeile:

vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  base: '/mein-repo-name/', // ← Dein Repo-Name!
  plugins: [react()],
})
5

Pushen und warten

Sobald du die Dateien committet hast, startet der Workflow automatisch. Unter dem Tab «Actions» im Repository kannst du den Fortschritt beobachten. Nach 2–3 Minuten ist die Seite live. Jeder neue Push startet einen neuen Build.

💾 Was genau passiert nach dem Commit? →
↑ Nach oben
Flussdiagramme
So verarbeitet GitHub Pages deine Inhalte – für jeden Weg visualisiert.

📝 Weg 1: Markdown Automatisch via Jekyll

index.mdText schreiben
💾 CommitÄnderung speichern
Push auf mainAutomatisch auf github.com
Jekyll BuildMarkdown → HTML
CDN 🌍Seite live!

🌐 Weg 2: HTML Direkte Auslieferung

index.htmlDatei hochladen
💾 CommitÄnderung speichern
Push auf mainAutomatisch auf github.com
Kein Build nötig1:1 Übernahme
CDN 🌍Seite live!

⚡ Weg 3: Lovable / Vite GitHub Actions Build

React + JSXApp-Quellcode
💾 CommitÄnderung speichern
Push auf mainTriggert Workflow
npm run buildApp kompilieren
dist/Fertiges HTML
CDN 🌍Seite live!
↑ Nach oben
Vergleich auf einen Blick
Welcher Weg bietet was?
📝 Markdown 🌐 HTML ⚡ Lovable / Vite
Vorkenntnisse Keine Grundlegendes HTML Keine (Lovable generiert)
Design-Freiheit Begrenzt (Themes) Volle Kontrolle Volle Kontrolle
Build nötig? Nein (Jekyll automatisch) Nein Ja (GitHub Actions)
Pages-Quelle Branch: main Branch: main GitHub Actions
Interaktivität Nur Text & Bilder HTML + JS möglich Volle App-Funktionalität
Ideal für Doku, Blog, Portfolio Statische Webseiten Web-Apps, Dashboards
Einrichtung ~5 Minuten ~5 Minuten ~15 Minuten
↑ Nach oben
💡 Tipps & Stolperfallen
Häufige Fragen und Probleme – und wie du sie vermeidest.
📄

Startseite muss index heissen

Egal welcher Weg: Die Startseite muss index.html oder index.md heissen – sonst zeigt GitHub eine Fehlermeldung an.

⏱️

Geduld nach dem Push

Es dauert 1–3 Minuten, bis Änderungen live sind. Manchmal hilft ein Hard-Refresh im Browser (Ctrl + Shift + R), um den Cache zu leeren.

🔒

Public vs. Private

GitHub Pages ist kostenlos für öffentliche Repos. Für private Repos brauchst du GitHub Pro, Team oder Enterprise.

🔗

Base-Path bei Vite nicht vergessen

Ohne base: '/repo-name/' in vite.config.ts werden CSS, JS und Bilder nicht geladen – die Seite bleibt weiss.

🌐

Custom Domain möglich

Du kannst eine eigene Domain (z.B. meineseite.ch) verbinden. Dafür brauchst du eine CNAME-Datei im Repo und einen DNS-Eintrag beim Domain-Anbieter.

🚫

Keine Datenbank möglich

GitHub Pages hostet nur statische Inhalte. Für Datenbanken, Login-Systeme oder serverseitige Logik brauchst du einen anderen Hosting-Anbieter (z.B. Vercel, Netlify).

↑ Nach oben
🔒 Datenschutz & GitHub Pages
Wann ist eine GitHub Pages-Seite datenschutzkonform – und wann nicht? Zwei Szenarien im Vergleich.
✓ Datenschutzkonform

Reine HTML-Seite

Statische Seite ohne externe Dienste – z.B. mit Claude erstellt und als HTML-Datei hochgeladen.

🤖
Claude erstellt HTML-Datei
Reiner HTML/CSS/JS-Code, keine externen Datenverbindungen
⬆️
Upload auf GitHub
Datei wird im Repository gespeichert – kein Backend
🌐
GitHub Pages liefert Datei aus
Statischer Fileserver – kein serverseitiger Code
Keine Datenverarbeitung durch Betreiber
👤
Browser des Besuchers
Rendert HTML lokal – keine Daten verlassen den Browser
Kein Tracking · Keine Cookies
Hinweis: GitHub-Server GitHub speichert technische Access-Logs (IP, Timestamp). Dies liegt im Verantwortungsbereich von GitHub, nicht des Seitenbetreibers.
⚠ Prüfung erforderlich

HTML mit externen Diensten

Gleiche Basis, aber mit eingebundenen Drittdiensten – trotz statischer Seite fliessen Daten ab.

📄
HTML mit Einbindungen
Google Fonts, Analytics, Kontaktformular, Social-Widgets…
⬆️
Upload auf GitHub Pages
Datei identisch hochgeladen – der enthaltene Code ist das Problem
🌐
GitHub Pages liefert Datei aus
Wie bei der sicheren Variante – statisch, kein eigener Server-Code
⚠️
Browser lädt externe Ressourcen
Scripts kontaktieren Drittserver automatisch beim Seitenaufruf
IP-Adresse → Google, Meta, etc.
→ Datenübertragung in die USA
Typische Datenabflüsse Google Fonts (IP), Google Analytics (Verhalten), Formspree/Netlify Forms (Formulardaten), YouTube-Embeds (Cookies), Font Awesome CDN (IP bei jedem Aufruf)
// Fazit & Schlüsselpunkte
Statisch ≠ automatisch konform. GitHub Pages verarbeitet serverseitig keine Daten für den Betreiber – aber clientseitiges JavaScript kann sehr wohl Daten an Dritte senden.
Seiten ohne Drittdienste (z.B. mit Claude generierte HTML-Dateien) sind in der Regel datenschutzkonform: kein Tracking, keine externen Requests, keine Cookies.
Kritische Einbindungen: Google Fonts, Analytics, Font Awesome CDN, Social-Buttons oder Formulardienste senden Besucherdaten an Dritte – auch ohne eigenes Backend.
GitHub als Hoster speichert technische Logs (IP, Timestamps). Das liegt in GitHubs Datenschutzverantwortung und ist im DPA geregelt – nicht Aufgabe des Seitenbetreibers.
↑ Nach oben
URL-Struktur
https:// username .github.io / repo-name
stefan.github.io/meine-seite
stefan.github.io/portfolio
stefan.github.io/lovable-app