Git-Befehle: Das Lexikon für Einsteiger und Teams

Git ist das meistgenutzte Versionskontrollsystem der Welt — und wer einmal anfängt, es ernsthaft zu nutzen, merkt schnell: Die Befehle sind überschaubar. Das Problem ist nicht die Menge, sondern das Verständnis dahinter. Was macht git reset wirklich? Wann nutze ich rebase statt merge? Und warum funktioniert git push gerade nicht?

Dieses Lexikon gibt Ihnen Antworten. Es ist kein Tutorial und kein Roman — sondern ein strukturiertes Nachschlagewerk. Jeder Befehl wird erklärt, mit einem Codebeispiel versehen und mit einem klaren Hinweis versehen, wann er gehört und wann er gefährlich werden kann.

Inhalt:

Installation & Einrichtung

Bevor Git genutzt werden kann, muss es installiert und konfiguriert sein. Dieser Schritt ist einmalig — danach gilt die Konfiguration für alle Projekte auf dem Rechner.

Was das für Sie bedeutet

Wer Git zum ersten Mal einrichtet, ist in wenigen Minuten startklar. Wer im Team arbeitet, sollte alle Mitglieder mit identischer Konfiguration einrichten — das verhindert Verwirrung in der Commit-Historie.

Installation

Unter Windows: Git herunterladen und installieren. Danach steht das Git-Bash-Terminal zur Verfügung.

Unter Mac (via Homebrew):

brew install git

Unter Linux (Debian/Ubuntu):

apt-get install git

git config --global user.name

Setzt den Namen, der bei jedem Commit als Autor erscheint. Wird einmalig pro Rechner gesetzt.

git config --global user.name "Ihr Name"

Wann nutzen: Beim ersten Einrichten von Git auf einem neuen Rechner.

git config --global user.email

Setzt die E-Mail-Adresse, die mit jedem Commit verknüpft wird. Sollte mit der GitHub-E-Mail-Adresse übereinstimmen.

git config --global user.email ihre.email@beispiel.de

Wann nutzen: Beim ersten Einrichten, gemeinsam mit dem Benutzernamen.

git config --global core.editor

Legt fest, welcher Editor für Commit-Nachrichten geöffnet wird. Ohne diese Einstellung öffnet Git den Standard-Terminal-Editor — häufig Vim, der für Einsteiger ungewohnt ist.

git config --global core.editor "code --wait"

Wann nutzen: Wer VS Code nutzt und lange Commit-Nachrichten bequem schreiben möchte.

git config --global pull.rebase

Bestimmt, wie sich git pull verhält wenn lokale und remote Commits auseinanderlaufen — ob Commits zusammengeführt (merge) oder umgeschrieben werden (rebase).

git config --global pull.rebase false   # Merge-Verhalten (Standardeinstellung)
git config --global pull.rebase true    # Rebase-Verhalten

Wann nutzen: Empfehlung für Einsteiger: false (Merge) — das Verhalten ist vorhersehbarer.

Basis-Befehle

Diese Befehle sind das tägliche Handwerk in Git. Wer sie kennt und versteht, beherrscht den Kern des Systems — alles weitere baut darauf auf.

Was das für Sie bedeutet

Die folgenden Befehle bilden den Zyklus, den jede Änderung durchläuft: Bearbeiten → Vormerken → Speichern. Wer diesen Dreischritt verinnerlicht hat, arbeitet strukturiert und nachvollziehbar — unabhängig von der Projektgröße.

git init

Erstellt ein neues, leeres Git-Repository im aktuellen Verzeichnis. Dabei wird ein versteckter .git-Ordner angelegt, der die gesamte Versionshistorie speichert.

git init

Wann nutzen: Wenn ein neues Projekt lokal gestartet wird und noch kein Repository existiert.

git status

Zeigt den aktuellen Zustand des Arbeitsverzeichnisses: Welche Dateien wurden geändert? Welche sind bereits für den nächsten Commit vorgemerkt? Nicht vorgemerkte Dateien erscheinen rot, vorgemerkte grün.

git status

Wann nutzen: Immer — vor git add, nach git add, vor git commit. Dieser Befehl ist der schnellste Überblick über den aktuellen Stand.

git add

Verschiebt Änderungen in den Staging-Bereich — die Warteschlange vor dem Commit. Sie entscheiden selbst, welche Änderungen zusammengehören und gemeinsam gespeichert werden sollen.

git add index.html          # Einzelne Datei vormerken
git add .                   # Alle geänderten Dateien vormerken

Wann nutzen: Nachdem Änderungen gemacht wurden, bevor ein Commit erstellt wird.

git commit

Erstellt einen dauerhaften Speicherpunkt — einen sogenannten Commit — in der Projekthistorie. Jeder Commit sollte eine klare, beschreibende Nachricht enthalten: Was wurde geändert, und warum?

git commit -m "Kontaktformular: Pflichtfeld Telefon entfernt"

Wann nutzen: Wenn eine Änderung abgeschlossen ist und einen eigenständigen Zweck erfüllt. Faustformel: Lieber öfter committen als seltener.

git log

Zeigt die vollständige Commit-Historie in umgekehrter chronologischer Reihenfolge — mit Commit-ID, Autor, Datum und Nachricht.

git log

Wann nutzen: Um nachzuvollziehen, was wann von wem geändert wurde. Praktisch auch um Commit-IDs für git reset oder git revert zu finden.

git log --oneline

Zeigt die Commit-Historie komprimiert: eine Zeile pro Commit mit verkürzter ID und Nachricht. Deutlich übersichtlicher als git log bei vielen Commits.

git log --oneline

Wann nutzen: Für einen schnellen Überblick über die letzten Commits ohne Details.

git reflog

Zeigt eine private Aufzeichnung aller Aktionen im Repository — auch Branches, die gelöscht wurden, und Commits, die rückgängig gemacht wurden. Diese Logs werden nicht auf GitHub hochgeladen.

git reflog

Wann nutzen: Als Rettungsanker — wenn ein git reset --hard zu weit gegangen ist und ein früherer Zustand wiederhergestellt werden soll.

Branches

Ein Branch ist ein separater Entwicklungszweig. Während auf dem Hauptzweig (main) die stabile Version liegt, können neue Features, Bugfixes oder Experimente in eigenen Branches entwickelt werden — ohne den funktionierenden Stand zu gefährden.

Was das für Sie bedeutet

Branches kosten nichts und lassen sich jederzeit anlegen und löschen. Im Teamkontext sind sie unverzichtbar: Kein Entwickler arbeitet auf dem Hauptzweig direkt. Änderungen werden im Branch entwickelt, geprüft und erst dann zusammengeführt.

git branch

Zeigt alle lokalen Branches. Der aktive Branch ist mit einem Sternchen markiert.

git branch

Wann nutzen: Um sich zu orientieren — auf welchem Branch bin ich gerade? Welche Branches existieren?

git branch -r

Zeigt alle Remote-Branches auf GitHub (oder einem anderen Remote).

git branch -r

Wann nutzen: Um zu sehen, welche Branches auf GitHub existieren — besonders nützlich im Team.

git branch -a

Zeigt alle lokalen und remote Branches in einer gemeinsamen Liste.

git branch -a

git branch [name]

Erstellt einen neuen Branch mit dem angegebenen Namen — wechselt aber nicht automatisch dorthin.

git branch neues-feature

Wann nutzen: Wenn ein Branch vorbereitet werden soll, bevor zu ihm gewechselt wird.

git checkout [name]

Wechselt zu einem anderen Branch. Alle Dateien im Arbeitsverzeichnis werden auf den Stand des Zielbranches aktualisiert.

git checkout neues-feature

Wann nutzen: Um zwischen bestehenden Branches zu wechseln.

git checkout -b [name]

Erstellt einen neuen Branch und wechselt sofort dorthin — die häufig genutzte Kombination aus git branch und git checkout.

git checkout -b neues-feature

Wann nutzen: Zu Beginn jeder neuen Aufgabe oder jedem neuen Feature.

git branch -d [name]

Löscht einen Branch, der bereits in den Hauptbranch gemerged wurde. Git verweigert das Löschen, wenn der Branch noch nicht gemerged ist.

git branch -d neues-feature

Wann nutzen: Nach erfolgreichem Merge, um die Branch-Liste sauber zu halten.

git branch -D [name]

Löscht einen Branch auch dann, wenn er noch nicht gemerged oder auf GitHub hochgeladen wurde. Die großgeschriebene Version erzwingt die Löschung.

git branch -D experiment

Wann nutzen: Wenn ein experimenteller Branch verworfen werden soll. Achtung: Die darin enthaltenen Commits sind danach nicht mehr direkt erreichbar — nur über git reflog wiederherstellbar.

Remote & GitHub

Lokale Repositories existieren nur auf dem eigenen Rechner. Über Remote-Repositories — zum Beispiel auf GitHub — werden Änderungen mit dem Team geteilt, gesichert und gemeinsam verwaltet.

Was das für Sie bedeutet

Das Remote-Repository ist der gemeinsame Ankerpunkt des Teams. Alle laden dort hoch (push) und holen sich den aktuellen Stand (pull). Wer das Prinzip versteht, versteht den Kern der Teamarbeit mit Git.

git clone

Erstellt eine vollständige lokale Kopie eines Remote-Repositories — inklusive gesamter Historie und automatisch eingerichteter Remote-Verbindung.

git clone git@github.com:nutzername/projekt.git

Wann nutzen: Einmalig, wenn ein bestehendes Projekt auf einen neuen Rechner geholt wird.

git remote add origin

Verbindet ein lokales Repository mit einem Remote-Repository. Der Alias origin ist Konvention und kann beliebig benannt werden.

git remote add origin git@github.com:nutzername/projekt.git

Wann nutzen: Wenn ein lokales Projekt mit git init gestartet und nachträglich mit GitHub verbunden werden soll.

git remote

Listet alle Remote-Verbindungen des lokalen Repositories nach ihrem Alias.

git remote

git remote -v

Listet alle Remote-Verbindungen mit der vollständigen URL — nützlich um zu prüfen, wohin push und pull zeigen.

git remote -v

git push -u origin [branch]

Lädt den lokalen Branch auf GitHub hoch und verknüpft ihn dauerhaft mit dem Remote-Branch. Nach dieser einmaligen Verknüpfung reicht git push für alle weiteren Uploads.

git push -u origin main

Wann nutzen: Beim ersten Push eines neuen Branches auf GitHub.

git push

Lädt die lokalen Commits auf den verknüpften Remote-Branch hoch. Funktioniert nur, wenn die Verknüpfung bereits mit git push -u gesetzt wurde.

git push

Wann nutzen: Nach jedem Commit, der auf GitHub sichtbar sein soll.

git push origin [branch]

Lädt den lokalen Branch explizit auf den angegebenen Remote-Branch hoch — auch ohne vorherige Verknüpfung.

git push origin neues-feature

Wann nutzen: Für neue Branches, die noch keine Verknüpfung haben, oder wenn ein bestimmter Remote-Branch gezielt angesprochen werden soll.

git pull

Holt die neuesten Commits vom Remote-Branch und integriert sie in den aktuellen lokalen Branch. Entspricht einer Kombination aus git fetch und git merge.

git pull

Wann nutzen: Zu Beginn jeder Arbeitssitzung — um sicherzustellen, dass der lokale Stand aktuell ist.

git pull origin [branch]

Holt Commits von einem bestimmten Remote-Branch und integriert sie in den aktuellen lokalen Branch.

git pull origin main

Wann nutzen: Wenn der aktuelle Branch mit den neuesten Änderungen aus main aktualisiert werden soll — typisch vor einem Merge oder nach längerem Arbeiten auf einem Feature-Branch.

Merge & Rebase

Beide Befehle bringen Änderungen aus verschiedenen Branches zusammen — aber auf unterschiedliche Arten. Die Wahl zwischen Merge und Rebase hat Konsequenzen für die Lesbarkeit der Commit-Historie.

Was das für Sie bedeutet

Für Teams gilt die Regel: Merge für öffentliche Branches, Rebase nur für private Branches. Wer Rebase auf einem bereits hochgeladenen Branch ausführt, schreibt die Geschichte um — was zu Konflikten bei allen führt, die diesen Branch bereits haben.

git merge [branch]

Führt den angegebenen Branch in den aktuellen Branch zusammen. Bei Konflikten zeigt Git diese an und wartet auf manuelle Auflösung. In der Commit-Historie entsteht ein sogenannter Merge-Commit.

git merge neues-feature

Wann nutzen: Immer wenn ein Feature-Branch in main übernommen werden soll. Auch geeignet wenn die Commit-Historie vollständig und nachvollziehbar bleiben soll.

git rebase [branch]

Setzt die Commits des aktuellen Branches so um, als wären sie nach den Commits des angegebenen Branches entstanden. Die Commit-Historie wirkt dadurch linearer und aufgeräumter.

git rebase main

Wann nutzen: Auf privaten Feature-Branches, die noch nicht auf GitHub hochgeladen wurden. Typisch: Bevor ein Pull Request geöffnet wird, um den Feature-Branch auf den aktuellen Stand von main zu bringen. Achtung: Niemals auf Branches ausführen, die bereits im Team genutzt werden — Rebase schreibt die Commit-Geschichte neu.

Reset & Revert

Beide Befehle machen Änderungen rückgängig — aber auf grundlegend verschiedene Arten. Die Wahl hängt davon ab, ob die betroffenen Commits bereits auf GitHub veröffentlicht wurden oder nicht.

Was das für Sie bedeutet

Die einfache Regel: Wurden die Commits bereits hochgeladen (git push), nutzen Sie git revert. Wurden sie nur lokal gespeichert, ist git reset möglich. Ein falsches git reset --hard auf einem geteilten Branch kann die Arbeit anderer gefährden.

git reset [commit-id]

Setzt den Verlauf zurück auf einen früheren Commit. Alle späteren Commits verschwinden aus der Geschichte — der Code selbst bleibt jedoch im Arbeitsverzeichnis erhalten und kann erneut gespeichert werden.

git reset 4965db1

Wann nutzen: Wenn lokale Commits zusammengefasst oder neu strukturiert werden sollen — vor dem ersten Push. Achtung: Niemals auf Branches verwenden, die bereits auf GitHub hochgeladen wurden.

git reset --hard [commit-id]

Setzt den Verlauf zurück auf einen früheren Commit — und löscht dabei auch alle Änderungen im Arbeitsverzeichnis. Es gibt kein Zurück außer über git reflog.

git reset --hard 4965db1

Wann nutzen: Wenn ein lokaler Branch vollständig auf einen früheren Zustand zurückgesetzt werden soll und alle Änderungen danach verworfen werden können. Achtung: Hochgradig destruktiv. Nur bei lokal unveröffentlichten Commits verwenden — und nur wenn bewusst alle Änderungen danach verloren gehen dürfen.

git revert [commit-id]

Erstellt einen neuen Commit, der die Änderungen des angegebenen Commits rückgängig macht — ohne die Geschichte zu löschen. Die ursprünglichen Commits bleiben sichtbar.

git revert 4965db1

Wann nutzen: Wenn ein Fehler auf einem Branch rückgängig gemacht werden soll, der bereits auf GitHub hochgeladen und vom Team genutzt wird. git revert ist die sichere Alternative zu git reset auf öffentlichen Branches.

Häufige Fragen

Muss ich Programmieren können, um Git zu nutzen?

Nein. Git ist ursprünglich für Code entwickelt worden, funktioniert aber für jede Art von Textdateien — Dokumentationen, Verträge, Konfigurationen, Marketingtexte. Wer die Kommandozeile meidet, kann auf grafische Oberflächen wie GitHub Desktop, Tower oder Sourcetree zurückgreifen.

Was ist der Unterschied zwischen `git fetch` und `git pull`?

git fetch holt die neuesten Informationen vom Remote-Repository — aktualisiert aber noch keine lokalen Dateien. git pull führt git fetch und anschließend git merge in einem Schritt aus. Wer prüfen möchte, was sich remote geändert hat, bevor es lokal integriert wird, nutzt zuerst git fetch.

Warum funktioniert `git push` nicht, obwohl ich Änderungen gemacht habe?

Häufigste Ursachen: (1) Der Remote enthält neuere Commits — zuerst git pull ausführen. (2) Der Branch hat noch keine Verknüpfung mit dem Remote — git push -u origin [branchname] verwenden. (3) Fehlende Schreibberechtigung auf dem Remote-Repository.

Kann ich einen Commit-Text nachträglich ändern?

Ja — aber nur für den letzten Commit, der noch nicht hochgeladen wurde: git commit --amend -m "Neue Nachricht". Bei bereits gepushten Commits ist eine Änderung möglich, aber schreibt die Geschichte um und sollte im Team abgesprochen sein.

Was ist ein Pull Request?

Ein Pull Request (PR) ist kein Git-Befehl, sondern ein GitHub-Feature. Er signalisiert dem Team: "Mein Branch ist fertig, bitte prüft und merged ihn." Im PR können Änderungen kommentiert, diskutiert und genehmigt werden — bevor der Code in den Hauptbranch gelangt.

Warum nicht einfach Dropbox oder SharePoint?

Diese Tools synchronisieren Dateien — aber sie verfolgen keine Änderungen auf Zeilenebene, ermöglichen keine parallele Arbeit in Branches und bieten keinen strukturierten Review-Prozess. Für reine Ablage reicht Dropbox. Für kollaborative Entwicklungsarbeit an gemeinsamen Dateien braucht man Git.

Fazit

Git-Befehle sind überschaubar — das Problem ist nicht die Menge, sondern das Verständnis dahinter. Wer weiß, warum git revert sicherer ist als git reset --hard, wann Rebase sinnvoll ist und was der Staging-Bereich leisten soll, nutzt Git souverän statt zögerlich.

Dieses Lexikon ist als Nachschlagewerk gedacht — nicht als einmalige Lektüre. Lesezeichen setzen, bei Bedarf zurückkehren. Den Einstieg in Git & GitHub im Team finden Sie in unserem Einführungsartikel.

Nächster Schritt: Wenn Ihr Team Git einführen oder die eigene Git-Struktur professionalisieren möchte, sprechen Sie uns an. Wir richten Git-Workflows ein, die zu Ihrem Arbeitsablauf passen — von der ersten Konfiguration bis zum automatisierten Deployment.