GitHub ist heute die zentrale Plattform für Softwareentwicklung weltweit. Ob Open-Source-Projekte, private Repositories oder die Zusammenarbeit im Team – ohne GitHub kommt kaum ein modernes Entwickler-Workflow aus. Wer neu in die Welt der Webentwicklung einsteigt, stolpert schnell über Begriffe wie Repository, Commit, Branch oder Pull Request. Dieser Artikel erklärt alle wichtigen Konzepte Schritt für Schritt und zeigt, wie man GitHub effektiv nutzt.
Was ist GitHub überhaupt?
GitHub ist eine webbasierte Plattform, die auf dem Versionskontrollsystem Git aufbaut. Während Git selbst ein Kommandozeilenwerkzeug ist, bietet GitHub eine grafische Oberfläche, Cloud-Hosting für Code und zahlreiche Collaboration-Features. Entwickler laden ihren Code in sogenannte Repositories hoch, verfolgen Änderungen über die Zeit und arbeiten gemeinsam an Projekten – alles zentral an einem Ort.
GitHub gehört seit 2018 zu Microsoft und zählt heute über 100 Millionen registrierte Nutzer. Die Plattform hostet Millionen von Open-Source-Projekten, darunter bekannte Frameworks wie React, Vue.js oder Linux selbst. Ein kostenloses Konto reicht für die meisten Einsteiger vollkommen aus.
Das Repository: Dein Projektordner in der Cloud
Ein Repository (kurz: Repo) ist der grundlegende Baustein auf GitHub. Es entspricht einem Projektordner, der alle Dateien, den kompletten Verlauf aller Änderungen und die Projektdokumentation enthält. Man unterscheidet zwischen öffentlichen Repositories, die jeder einsehen kann, und privaten Repositories, die nur für eingeladene Mitarbeiter sichtbar sind.
Ein neues Repository erstellt man direkt im Browser: Nach dem Einloggen auf github.com klickt man auf „New repository", gibt einen Namen ein, wählt Public oder Private und initialisiert das Repo optional mit einer README-Datei. Anschließend klont man es lokal mit dem Befehl git clone https://github.com/benutzername/projektname.git.
Commits: Änderungen festhalten
Ein Commit ist ein Schnappschuss des aktuellen Projektstands. Jede bedeutsame Änderung – eine neue Funktion, ein Bugfix, eine überarbeitete Dokumentation – wird als eigener Commit gespeichert. Commits bilden damit die vollständige Geschichte eines Projekts ab und lassen sich jederzeit abrufen oder rückgängig machen.
Der typische Workflow sieht so aus: Dateien bearbeiten, mit git add . für den Commit vormerken (sogenanntes „Staging"), dann mit git commit -m "Beschreibung der Änderung" speichern und schließlich mit git push zu GitHub hochladen. Eine gute Commit-Message beschreibt knapp, was geändert wurde und warum.
Branches: Parallel arbeiten ohne Chaos
Ein Branch (Zweig) ermöglicht es, parallel an verschiedenen Features oder Bugfixes zu arbeiten, ohne den Haupt-Code zu beeinflussen. Standardmäßig gibt es den main-Branch (früher: master), der den stabilen, produktionsreifen Code enthält. Neue Features werden in separaten Branches entwickelt und erst nach Überprüfung in den main-Branch gemergt.
Einen neuen Branch erstellt man mit git checkout -b mein-feature. Nach Abschluss der Arbeit schiebt man ihn mit git push origin mein-feature zu GitHub und öffnet dort einen Pull Request.
Pull Requests: Code-Reviews kollaborativ gestalten
Ein Pull Request (PR) ist eine Anfrage, Änderungen aus einem Branch in einen anderen – meist den main-Branch – zu übernehmen. PRs sind das Herzstück der kollaborativen Entwicklung auf GitHub. Sie ermöglichen Code-Reviews, Diskussionen über einzelne Codezeilen und automatisierte Tests, bevor neuer Code in das Projekt einfließt.
Beim Erstellen eines PRs wählt man Quell- und Zielbranch, fügt eine Beschreibung hinzu und kann Reviewer zuweisen. Kollegen können Kommentare hinterlassen, Änderungen anfordern oder den PR genehmigen. Erst nach Genehmigung wird der Code gemergt.
Issues: Aufgaben und Fehler verwalten
Issues sind das integrierte Aufgabenverwaltungssystem von GitHub. Hier werden Bugs gemeldet, neue Features diskutiert und Aufgaben verfolgt. Issues können mit Labels kategorisiert, Personen zugewiesen und mit Milestones versehen werden. Über References (#42 in einer Commit-Message) lassen sich Issues direkt mit Commits oder PRs verknüpfen.
Fork-Workflow: So trägt man zu Open-Source bei
Der Fork-Workflow ist das Standardvorgehen für Beiträge zu fremden Projekten. Man erstellt eine eigene Kopie (Fork) des Repositories, nimmt dort Änderungen vor und sendet dann einen Pull Request an das ursprüngliche Projekt. Der Maintainer prüft die Änderungen und kann sie übernehmen.
| Schritt | Aktion | Befehl / Ort |
|---|---|---|
| 1. Fork erstellen | Eigene Kopie des Original-Repos anlegen | GitHub-Button „Fork" |
| 2. Lokal klonen | Fork auf den eigenen Rechner laden | git clone <fork-url> |
| 3. Branch erstellen | Neuen Feature-Branch anlegen | git checkout -b mein-fix |
| 4. Änderungen machen | Code bearbeiten und committen | git commit -m "Fix: ..." |
| 5. Pushen | Branch zum eigenen Fork hochladen | git push origin mein-fix |
| 6. Pull Request | PR an das Original-Repo senden | GitHub-Oberfläche |
| 7. Review abwarten | Auf Feedback des Maintainers reagieren | GitHub Kommentare |
GitHub Pages: Kostenlose Website für Projekte
GitHub Pages ermöglicht es, statische Websites direkt aus einem Repository heraus kostenlos zu hosten. Ideal für Projekt-Dokumentationen, Portfolio-Seiten oder einfache Landing Pages. Man aktiviert GitHub Pages in den Repository-Einstellungen, wählt einen Branch als Quelle und die Seite ist unter benutzername.github.io/projektname erreichbar. Mit Jekyll lassen sich sogar vollständige Blogs betreiben.
Stars und Forks: Die soziale Seite von GitHub
Stars sind das Äquivalent zum „Like" auf GitHub. Durch das Markieren eines Repositories mit einem Stern zeigt man Wertschätzung und behält interessante Projekte im Blick. Die Anzahl der Stars gilt als informeller Indikator für die Beliebtheit eines Projekts. Forks hingegen sind tatsächliche Kopien eines Repositories in den eigenen Account – entweder um beizutragen oder um das Projekt in eine eigene Richtung weiterzuentwickeln.
.gitignore-Datei, um solche Dateien systematisch auszuschließen.
Häufig gestellte Fragen
- Was ist der Unterschied zwischen Git und GitHub?
- Git ist das Versionskontrollsystem, das lokal auf dem Rechner läuft und Änderungen verfolgt. GitHub ist eine Online-Plattform, die Git-Repositories hostet und Collaboration-Features wie Pull Requests, Issues und GitHub Actions hinzufügt. Man kann Git vollständig ohne GitHub nutzen, aber nicht umgekehrt.
- Wie viele Repositories kann ich kostenlos erstellen?
- Mit einem kostenlosen GitHub-Konto kann man unbegrenzt viele öffentliche und private Repositories erstellen. Private Repositories mit erweiterten Features wie Code-Ownership oder Protected Branches sind in den kostenpflichtigen Plänen (GitHub Team, GitHub Enterprise) enthalten.
- Was passiert, wenn zwei Personen dieselbe Datei gleichzeitig bearbeiten?
- Dann entsteht ein sogenannter Merge-Konflikt. Git versucht, die Änderungen automatisch zusammenzuführen. Gelingt das nicht, werden die betroffenen Stellen in der Datei markiert und müssen manuell aufgelöst werden. Anschließend erstellt man einen neuen Commit mit der aufgelösten Version.
- Kann ich mit GitHub auch ohne Kommandozeile arbeiten?
- Ja. Die GitHub Desktop App bietet eine grafische Oberfläche für die häufigsten Git-Operationen wie Klonen, Committen, Pushen und Mergen. Für Einsteiger ist das eine gute Alternative zur Kommandozeile, bis man sich mit den Git-Befehlen vertraut gemacht hat.