Git und GitHub: Was ist der Unterschied und wie hängen sie zusammen?

Git und GitHub werden ständig verwechselt, obwohl sie auf verschiedenen Ebenen liegen. Git ist ein Versionskontrollprogramm, das Sie auf Ihrem Rechner installieren: Es merkt sich jeden gespeicherten Zustand des Projekts und erlaubt die Rückkehr dorthin. GitHub ist ein Webdienst, auf dem Kopien von Git-Repositories liegen und um den herum Werkzeuge für die Teamarbeit gebaut sind. Am einfachsten merken Sie es sich so: Git ist der Motor, GitHub die Werkstatt mit Service, in die man diesen Motor stellen kann.

Was ist Git?

Git ist ein verteiltes Versionskontrollsystem. Linus Torvalds hat es 2005 für die Entwicklung des Linux-Kernels geschaffen, und seitdem ist es Industriestandard. Git arbeitet vollständig lokal: Die Änderungshistorie liegt im versteckten Ordner .git im Projekt, und für die meisten Operationen brauchen Sie kein Internet.

Das Wort „verteilt“ ist hier entscheidend. Jeder Projektbeteiligte hat auf seinem Rechner eine vollständige Kopie des Repositorys mit der gesamten Historie, nicht nur die neuesten Dateien. Fällt der Server aus, lässt sich das Projekt von jedem Arbeitsrechner wiederherstellen.

Was Git allein kann:

• Änderungen in Commits festhalten – Momentaufnahmen des Projekts mit Autor, Datum und Beschreibung;
• zeigen, wer eine bestimmte Zeile wann und warum geändert hat (git log, git blame);
• parallele Entwicklungslinien in Branches führen und zusammenführen;
• Fehler rückgängig machen, ohne die übrige Arbeit zu verlieren;
• Historie mit anderen Repositories über git push, git pull und git fetch austauschen.

Git ist ein Kommandozeilenwerkzeug. Grafische Clients und in Editoren eingebaute Ansichten (VS Code, IntelliJ IDEA) sind nur Oberflächen für dieselben Befehle.

Was ist GitHub?

GitHub ist eine Cloud-Plattform zum Hosten von Git-Repositories und gehört heute Microsoft. Sie legen dort ein Repository an, schicken Ihren lokalen Code mit git push hinein, und er ist für Kollegen, Arbeitgeber oder – bei einem öffentlichen Repository – das ganze Internet zugänglich.

Der Wert von GitHub liegt aber nicht nur in der Speicherung. Rund um das Repository fügt GitHub hinzu, was Git selbst nicht hat:

• Pull Requests – Anfragen zum Mergen eines Branches mit Diskussion und zeilenweisem Code-Review;
• Issues – Aufgaben und Fehlerberichte, die an das Projekt gebunden sind;
• GitHub Actions – CI/CD: automatisches Ausführen von Tests, Builds und Deployments bei jedem Push;
• Zugriffsverwaltung – wer lesen, schreiben und in geschützte Branches mergen darf;
• Entwicklerprofil – Aktivitätsgrafik und öffentliche Projekte, die sich Recruiter ansehen;
• GitHub Pages – kostenloses Hosting statischer Websites direkt aus dem Repository.

Suchanfragen wie „git com“ oder „git hub“ meinen in der Regel genau diesen Dienst – seine Adresse ist github.com. Die offizielle Website von Git selbst ist git-scm.com; dort lädt man den Installer herunter.

Git und GitHub im tabellarischen Vergleich

Wie Git und GitHub zusammenarbeiten

Die Verbindung zwischen beiden ist das Remote, das entfernte Repository. Das lokale Repository speichert die Adresse des GitHub-Repositorys unter einem kurzen Namen, standardmäßig origin. Der Austausch läuft dann über drei Befehle:

• git push – eigene neue Commits auf den Server schicken;
• git fetch – fremde Commits herunterladen, ohne Ihre Dateien anzurühren;
• git pull – herunterladen und die Änderungen sofort in den aktuellen Branch übernehmen (im Grunde fetch + merge oder rebase).

Wichtig: GitHub sieht Ihren Code nicht, bevor Sie ihn gepusht haben. Ein Commit existiert bis zum ersten git push nur lokal. Daher der häufige Einsteigerfehler: „Ich habe committet, aber auf GitHub ist nichts.“

Der typische Weg: vom lokalen Projekt zu GitHub

# 1. Repository lokal anlegen
cd my-project
git init
git add .
git commit -m "Erster Commit"

# 2. Leeres Repository auf github.com anlegen (ohne README),
#    Adresse kopieren und als Remote verbinden
git remote add origin git@github.com:username/my-project.git

# 3. Branch in main umbenennen und pushen
git branch -M main
git push -u origin main

Das Flag -u (Langform --set-upstream) verknüpft den lokalen Branch main mit dem Remote-Branch. Danach genügt einfach git push bzw. git pull ohne Argumente.

Der umgekehrte Weg: mit einem Repository auf GitHub starten

Liegt das Projekt bereits auf GitHub, wird es nicht neu angelegt, sondern geklont:

git clone https://github.com/username/my-project.git
cd my-project

Der Befehl lädt die gesamte Historie herunter und richtet das Remote origin automatisch ein.

Authentifizierung: SSH oder HTTPS

Seit 2021 akzeptiert GitHub bei der Arbeit mit Git über HTTPS kein Kontopasswort mehr. Es gibt zwei funktionierende Varianten.

HTTPS + Personal Access Token. Das Token wird in den Kontoeinstellungen erstellt (Settings → Developer settings) und statt des Passworts eingegeben. Damit Sie es nicht jedes Mal eintippen müssen, nutzt Git einen Credential Manager – unter Windows wird er mit Git for Windows installiert.

SSH-Schlüssel. Die Variante, die Arbeitgeber erwarten, dass Sie sie selbst einrichten können:

# Schlüssel erzeugen
ssh-keygen -t ed25519 -C "you@example.com"

# Öffentlichen Teil ausgeben und bei GitHub hinzufügen:
# Settings → SSH and GPG keys → New SSH key
cat ~/.ssh/id_ed25519.pub

# Verbindung prüfen
ssh -T git@github.com

Bei Erfolg antwortet GitHub mit einer Begrüßung samt Ihrem Benutzernamen und dem Hinweis, dass kein Shell-Zugang gewährt wird – das ist normal. Die Repository-Adresse müssen Sie dann im Format git@github.com:user/repo.git verwenden, nicht https://.

Ist das Repository bereits per HTTPS verbunden, stellen Sie es mit einem Befehl auf SSH um:

git remote set-url origin git@github.com:username/my-project.git

GitHub, GitLab und andere: die Unterschiede

GitHub ist nicht der einzige Git-Hoster. Alle arbeiten mit demselben Git, deshalb lässt sich ein Repository ohne Verlust der Historie von einem zum anderen umziehen. Sie unterscheiden sich in den Werkzeugen rund um den Code.

In GitLab heißt die Anfrage zum Zusammenführen Merge Request, in GitHub Pull Request – gemeint ist dasselbe: Änderungen aus einem Branch vorschlagen und vor dem Merge diskutieren. Die Begriffe unterscheiden sich, die Git-Befehle sind gleich.

In einem lokalen Repository können Sie mehrere Remotes gleichzeitig führen und das Projekt etwa sowohl auf GitHub als auch auf GitLab spiegeln:

git remote add gitlab git@gitlab.com:username/my-project.git
git push gitlab main
git remote -v

Brauche ich GitHub, wenn ich allein arbeite?

Technisch nicht: Git funktioniert lokal hervorragend. Doch ein Remote-Repository hat selbst für ein Einzelprojekt drei handfeste Vorteile.

• Backup. Ist der Laptop kaputt, liegen Code und gesamte Historie unversehrt auf dem Server.
• Arbeit von mehreren Geräten. Zu Hause und im Büro synchronisieren Sie über push und pull.
• Portfolio. Bei der Auswahl für Junior-Stellen wird das GitHub-Profil oft vor dem Lebenslauf angesehen: Gibt es lebendige Projekte, aussagekräftige Commit-Nachrichten, ein README?

Wie Einsteiger anfangen

Git und GitHub müssen Sie nicht gleichzeitig lernen – die Reihenfolge ist wichtig. Beherrschen Sie zuerst den lokalen Zyklus: git init, git status, git add, git commit, git log, Branches und Merges. Wenn das ohne Spickzettel klappt, registrieren Sie sich auf GitHub, richten SSH ein und lernen push, pull, fetch. Der letzte Schritt ist der Teamprozess: Fork, Branch pro Aufgabe, Pull Request, Review.

Worauf Arbeitgeber in Ihrem GitHub achten

Die grünen Aktivitätskästchen sind nicht das Wichtigste. Ein erfahrener Reviewer bewertet in wenigen Minuten anderes:

• verständliche Commit-Nachrichten statt „fix“, „123“, „Änderungen“;
• kleine, logische Commits statt eines riesigen „Projekt hochgeladen“;
• ein README, das beschreibt, wie man das Projekt startet;
• eine .gitignore: im Repository gibt es kein node_modules, keine .env mit Passwörtern, keine IDE-Dateien;
• Branches und Pull Requests selbst in Lernprojekten – das zeigt, dass Sie den Teamprozess kennen.

Typische Einsteigerfehler

„fatal: not a git repository“

Sie führen einen Git-Befehl außerhalb eines Repositorys aus. Wechseln Sie in den Projektordner oder führen Sie git init aus. Mit der Registrierung bei GitHub hat das nichts zu tun – es ist ein lokaler Git-Fehler.

„Permission denied (publickey)“

Der SSH-Schlüssel wurde nicht erzeugt, nicht bei GitHub hinterlegt oder nicht in den ssh-agent geladen. Prüfen Sie ssh -T git@github.com und die Schlüsselliste in den Kontoeinstellungen.

„rejected … (fetch first)“ beim Push

Auf dem Server liegen Commits, die Sie nicht haben – etwa weil Sie das Repository auf GitHub mit README angelegt haben. Holen Sie zuerst die Änderungen: git pull --rebase origin main, dann wiederholen Sie git push. Verwenden Sie --force nicht, solange Sie nicht verstehen, wessen Arbeit Sie überschreiben.

Geheimnisse in einem öffentlichen Repository

Ein Passwort oder API-Schlüssel, der einmal in einem Commit gelandet ist, bleibt in der Historie, selbst wenn die Datei später gelöscht wird. Einen solchen Schlüssel müssen Sie sofort neu ausstellen, und .env gehört von vornherein in die .gitignore.

Fazit

Git ist das Versionskontrollwerkzeug auf Ihrem Rechner, GitHub der Dienst, auf dem diese Repositories in der Cloud leben und um den herum die Teamarbeit organisiert wird. GitLab, Bitbucket und andere sind Alternativen zu GitHub, nicht zu Git: Unter der Haube stecken überall dieselben Commits, Branches und Befehle. Beginnen Sie mit lokalem Git, verbinden Sie dann ein Remote und richten Sie SSH ein. Die Verbindung eines lokalen Repositorys mit GitHub sowie push, pull und fetch üben wir praktisch im Git-Kurs.