GitHub Portfolio: Profil, Projekte und Portfolio-Website für Entwickler

Ein GitHub-Portfolio besteht aus drei Teilen: einem Profil-README, das in wenigen Sätzen sagt, wer du bist und woran du arbeitest, bis zu sechs angehefteten Repositorys mit deinen besten Projekten und optional einer Portfolio-Website auf GitHub Pages. Es überzeugt mit wenigen gepflegten Projekten mit gutem README, Tests und Demo, nicht mit vielen angefangenen.

Stand: 13. Oktober 2026. Die Funktionen und Grenzen stammen aus der Dokumentation von GitHub, abgerufen an diesem Tag. Die Quellen stehen am Ende. Was Arbeitgeber erwarten, ist hier als Einschätzung gekennzeichnet; belastbare Erhebungen dazu wurden nicht herangezogen.

Was ein GitHub-Portfolio ist

Ein GitHub-Portfolio ist dein öffentliches GitHub-Profil, aufbereitet für Leute, die dich einstellen oder beauftragen wollen. Es zeigt Code statt Behauptungen: Wer deinen Lebenslauf liest, kann mit einem Klick sehen, wie du Projekte aufbaust, dokumentierst und testest. Nach Einschätzung schaut dabei kaum jemand jede Datei an. Gelesen werden vor allem Profil, angeheftete Projekte und deren README.

Baustein	Zweck	Aufwand (Einschätzung)
Profil-README	Wer du bist, was du kannst, wie man dich erreicht	eine Stunde
angeheftete Repositorys (bis zu sechs)	deine besten Projekte zuerst zeigen	Minuten, wenn die Projekte stehen
README je Projekt	erklärt Zweck, Start und Technik	je Projekt ein bis zwei Stunden
Tests und CI	zeigen, dass du sauber arbeitest	je nach Projekt
Portfolio-Website (GitHub Pages)	ein schöner Einstieg mit Links und Demos	ein Nachmittag

Nicht verwechseln: Wer nach „GitHub Portfolio Performance“ sucht, meint meist ein anderes Projekt. Portfolio Performance ist eine Open-Source-Software, um die Wertentwicklung von Geldanlagen zu verfolgen; ihr Quellcode liegt auf GitHub unter der Eclipse Public License 1.0. Mit Entwickler-Portfolios hat sie nichts zu tun.

Das Profil-README einrichten

GitHub zeigt ein README direkt auf deiner Profilseite an, wenn vier Bedingungen erfüllt sind: Es gibt ein Repository mit genau deinem Benutzernamen, es ist öffentlich, es enthält im Hauptverzeichnis eine Datei README.md, und die Datei hat Inhalt. Heißt dein Konto octocat, muss das Repository also octocat heißen. Beim Anlegen über „New repository“ wählst du „Public“ und schaltest „Add README“ ein; GitHub füllt die Datei mit einer Vorlage.

Ein Profil-README muss nach Einschätzung nicht bunt sein. Wichtig sind drei Dinge: was du machst, woran du gerade arbeitest und wie man dich erreicht. Ein Beispiel:

# Alex Beispiel · Backend-Entwicklung

Node.js und PostgreSQL. Schwerpunkt: APIs, die auch nach dem
dritten Kunden noch wartbar sind.

**Gerade:** ein Abrechnungsdienst für kleine Vereine ([vereinskasse](https://github.com/DEINNAME/vereinskasse))

**Technik:** TypeScript, Node.js, PostgreSQL, Docker, GitHub Actions

**Kontakt:** name@example.org · [Portfolio](https://DEINNAME.github.io)

Das README ist ein Beispiel; der Name ist erfunden. Generatoren und Vorlagen für Profil-READMEs gibt es viele. Nach Einschätzung wirken Abzeichen-Wände und Statistik-Karten weniger als zwei klare Sätze und ein Link auf das beste Projekt.

Die richtigen Repositorys anheften

Ohne eigene Auswahl zeigt GitHub den Abschnitt „Popular repositories“. Über „Customize your pins“ wählst du bis zu sechs Repositorys und Gists zusammen aus und legst ihre Reihenfolge fest. Das ist der wichtigste Hebel: Wer dein Profil öffnet, sieht diese sechs Kacheln zuerst.

Nach Einschätzung gilt für die Auswahl: lieber drei starke als sechs mittelmäßige. Forks fremder Projekte ohne eigene Änderungen, Kursaufgaben und halbfertige Experimente gehören nicht nach oben.

Welche Projekte im Portfolio überzeugen

Die folgende Tabelle ist eine Einschätzung, welche Art von Projekt was zeigt. Sie beruht nicht auf einer Erhebung.

Projektart	zeigt	Beispiel
Werkzeug für ein echtes Problem	Verständnis für Nutzer, Produktdenken	Abrechnung für einen Verein, Skript, das eine lästige Aufgabe im Studium löst
Anwendung mit Datenbank, Anmeldung und Deployment	Überblick über den ganzen Weg bis zur Produktion	kleines SaaS mit Live-Demo
Beitrag zu einem bestehenden Open-Source-Projekt	Arbeiten in fremdem Code, Umgang mit Reviews	angenommener Pull Request mit Diskussion
Bibliothek oder CLI-Tool	saubere Schnittstellen, Dokumentation, Versionierung	kleines npm- oder PyPI-Paket
Nachbau eines bekannten Dienstes	Technik, aber wenig eigenes Denken	„Twitter-Klon“

Was alle guten Portfolio-Projekte nach Einschätzung gemeinsam haben: Sie lösen ein erkennbares Problem, laufen ohne Rätselraten, und man sieht, dass jemand Entscheidungen getroffen hat, statt einem Tutorial zu folgen. Wer gerade einsteigt, findet im Artikel Junior-Entwickler 2026: Deine Skills im KI-Zeitalter mehr zur Frage, was Berufsanfänger heute zeigen sollten.

Ein README, das ein Projekt erklärt

GitHub nennt in seiner Dokumentation fünf Fragen, die ein README beantworten sollte: was das Projekt tut, warum es nützlich ist, wie man damit anfängt, wo es Hilfe gibt und wer es pflegt. Liegt die Datei im Hauptverzeichnis, in docs oder im versteckten Ordner .github, zeigt GitHub sie automatisch an. Für ein Portfolio-Projekt bietet sich dieser Aufbau an:

# Vereinskasse

Mitgliedsbeiträge für kleine Vereine verwalten, ohne Tabellenkalkulation.
Live-Demo: https://vereinskasse.example.org (Testzugang: demo / demo)

![Screenshot der Beitragsübersicht](docs/screenshot.png)

## Warum
Kassenwarte pflegen Beiträge oft in Tabellen, die niemand sonst versteht.

## Schnellstart
    git clone https://github.com/DEINNAME/vereinskasse
    cd vereinskasse
    cp .env.example .env
    docker compose up

## Technik und Entscheidungen
- Node.js und PostgreSQL, weil Buchungen Transaktionen brauchen
- Keine Kartenzahlung im Projekt, Überweisungen werden importiert

## Tests
    npm test

## Lizenz
MIT

Der Abschnitt „Technik und Entscheidungen“ ist nach Einschätzung der wertvollste: Er zeigt, dass du abgewogen hast. Ein Screenshot oder eine Live-Demo erspart dem Leser, das Projekt selbst zu starten.

Tests und CI sichtbar machen

Ein Projekt mit automatischen Tests, die bei jedem Push laufen, wirkt nach Einschätzung deutlich reifer als eines ohne. Mit GitHub Actions reicht dafür eine Datei .github/workflows/test.yml. Die Schritte folgen dem Beispiel aus der Dokumentation von actions/setup-node:

name: Tests
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      - run: npm test

Die Datei wurde als gültiges YAML geprüft; in einem echten Repository ausgeführt wurde sie für diesen Artikel nicht. Den Status zeigst du im README mit einem Abzeichen, dessen Adresse GitHub nach dem Muster https://github.com/OWNER/REPOSITORY/actions/workflows/WORKFLOW-FILE/badge.svg bildet. Wie du daraus eine vollständige Pipeline mit Deployment machst, zeigt CI/CD für Solo-Devs.

Lizenz: ohne sie darf niemand deinen Code nutzen

Viele Portfolio-Repositorys haben keine Lizenzdatei. GitHub weist darauf hin, was das bedeutet: Ohne Lizenz gilt das Urheberrecht, du behältst alle Rechte, und niemand darf den Code vervielfältigen, verbreiten oder darauf aufbauen. Andere Nutzer dürfen ein öffentliches Repository nach den Nutzungsbedingungen von GitHub aber ansehen und forken. Wer möchte, dass andere den Code verwenden, legt eine Open-Source-Lizenz bei; GitHub empfiehlt das für Open-Source-Projekte ausdrücklich.

Contribution-Graph und private Arbeit

Der Kalender mit grünen Kästchen zeigt, wann du aktiv warst. Wer die meiste Arbeit in privaten Repositorys macht, etwa beim Arbeitgeber, kann über „Contribution settings“ oberhalb des Kalenders „Private contributions“ einschalten. GitHub zeigt dann anonymisierte Aktivität aus privaten und internen Repositorys, ohne Inhalte preiszugeben. Nach Einschätzung ist der Kalender ohnehin ein schwaches Signal: Regelmäßige kleine Commits sagen wenig über die Qualität der Arbeit.

Portfolio-Website mit GitHub Pages

GitHub Pages veröffentlicht statische Websites aus HTML, CSS und JavaScript direkt aus einem Repository. In GitHub Free funktioniert das für öffentliche Repositorys, in bezahlten Tarifen auch für private. Für eine persönliche Seite unter https://DEINNAME.github.io muss das Repository DEINNAME.github.io heißen. Enthält dein Benutzername Großbuchstaben, schreibst du ihn dabei laut GitHub klein. Lege das leere Repository zuerst auf GitHub über „New repository“ an, in GitHub Free als öffentliches Repository; sonst scheitert der spätere git push. Dann:

mkdir DEINNAME.github.io && cd DEINNAME.github.io
git init -b main
echo '<!doctype html><title>Portfolio</title><h1>Hallo</h1>' > index.html
git add index.html && git commit -m "Portfolio-Seite"
git remote add origin git@github.com:DEINNAME/DEINNAME.github.io.git
git push -u origin main

DEINNAME ersetzt du durch deinen Benutzernamen in Kleinbuchstaben; die Befehle bis auf git push wurden in einem lokalen Testordner ausgeführt. Danach wählst du in den Einstellungen des Repositorys unter „Pages“ als Quelle „Deploy from a branch“ und den Branch main. Wer einen Static-Site-Generator mit eigenem Build nutzt, veröffentlicht laut GitHub besser über einen Actions-Workflow.

Für Pages gelten Grenzen:

Grenze	Wert laut GitHub
Größe der veröffentlichten Seite	höchstens 1 GB
Quell-Repository	empfohlene Grenze 1 GB
Bandbreite	weiche Grenze 100 GB im Monat
Builds	weiche Grenze 10 je Stunde, nicht bei eigenem Actions-Workflow
Dauer eines Deployments	Abbruch nach 10 Minuten
Nutzung	nicht als kostenloses Hosting für Online-Geschäfte, E-Commerce oder SaaS

Für ein Portfolio reicht das. Wer als Freelancer über die Seite Kunden gewinnen will, sollte die Nutzungsregel im Blick behalten und zusätzlich klären, welche Pflichtangaben für eine geschäftliche Website gelten; Hinweise dazu stehen im Artikel zur DSGVO-konformen Website.

Checkliste für dein GitHub-Portfolio

Punkt	erledigt, wenn
Profilbild, Name, Kurzbeschreibung	jemand in zehn Sekunden weiß, was du machst
Profil-README	drei Sätze plus Link auf das beste Projekt
angeheftete Repositorys	höchstens sechs, die stärksten zuerst
README je Projekt	Zweck, Screenshot oder Demo, Schnellstart, Entscheidungen, Lizenz
Tests	laufen per GitHub Actions bei jedem Push
Lizenz	Datei LICENSE in jedem Projekt, das andere nutzen dürfen
Aufräumen	alte Experimente archiviert oder privat

Quellen und Stand

Alle Angaben wurden am 13. Oktober 2026 geprüft an:

• GitHub Docs: Managing your profile README
• GitHub Docs: Pinning items to your profile
• GitHub Docs: Private contributions and achievements
• GitHub Docs: About READMEs und Licensing a repository
• GitHub Docs: What is GitHub Pages?, GitHub Pages limits und Publishing source
• GitHub Docs: Adding a workflow status badge
• actions/setup-node und actions/checkout
• Portfolio Performance auf GitHub

Häufige Fragen

Wie erstellt man ein GitHub-Portfolio?

Lege ein öffentliches Repository mit deinem Benutzernamen und einer README.md an; GitHub zeigt sie auf deinem Profil. Hefte dann bis zu sechs deiner besten Repositorys an, gib jedem ein README mit Zweck, Demo und Schnellstart und richte bei Bedarf eine Website unter DEINNAME.github.io mit GitHub Pages ein.

Wie erstellt man ein GitHub-Profil-README?

Über „New repository“ ein Repository anlegen, das genau so heißt wie dein Benutzername, „Public“ wählen und „Add README“ einschalten. Sobald die README.md im Hauptverzeichnis Inhalt hat, erscheint sie auf deiner Profilseite. Repositorys, die vor Juli 2020 so angelegt wurden, musst du laut GitHub einmal manuell freigeben.

Wie viele Projekte gehören in ein GitHub-Portfolio?

GitHub erlaubt bis zu sechs angeheftete Repositorys und Gists. Nach Einschätzung sind drei gut dokumentierte, lauffähige Projekte überzeugender als sechs halbfertige. Wichtiger als die Zahl ist, dass jedes Projekt ein erkennbares Problem löst und ein README hat.

Ist GitHub Pages kostenlos?

Für öffentliche Repositorys ist GitHub Pages in GitHub Free enthalten; private Repositorys brauchen einen bezahlten Tarif wie GitHub Pro. Die Seite darf höchstens 1 GB groß sein, für die Bandbreite gilt eine weiche Grenze von 100 GB im Monat. Als Hosting für Online-Shops oder SaaS ist Pages laut GitHub nicht gedacht.

Braucht man zusätzlich eine eigene Portfolio-Website?

Nicht zwingend. Für viele Bewerbungen reicht nach Einschätzung ein gepflegtes GitHub-Profil. Eine Website lohnt sich, wenn du Projekte zeigen willst, die nicht öffentlich auf GitHub liegen, oder wenn du als Freelancer Kunden ansprichst, die mit GitHub wenig anfangen können. Mehr dazu im Artikel Freelance Entwickler: Dein ehrlicher Fahrplan für den Start.

Was ist Portfolio Performance auf GitHub?

Ein anderes Thema: Portfolio Performance ist eine Open-Source-Software, mit der Anleger die Entwicklung ihrer Aktien, Kryptowährungen und anderer Anlagen verfolgen. Der Quellcode liegt auf GitHub unter der Eclipse Public License 1.0. Mit einem Entwickler-Portfolio auf GitHub hat sie nur den Namen gemeinsam.