Git lernen klingt erst einmal nach Kommandozeilen-Chaos – ist aber das wichtigste Werkzeug, das du als Entwickler oder Entwicklerin überhaupt beherrschen solltest. Git ist eine Versionskontrolle: Es speichert jeden Zwischenstand deines Codes, macht jede Änderung rückgängig und lässt dich mit anderen am selben Projekt arbeiten, ohne dass etwas verloren geht.
In diesem Guide erkläre ich dir Git so, wie ich es einem Freund am Küchentisch erklären würde: ohne Fachchinesisch, mit klaren Beispielen und einem Workflow, den du in zehn Minuten selbst ausprobieren kannst. Am Ende kennst du die wichtigsten Begriffe, die 7 zentralen Befehle und die Stolperfallen, die fast jeder Anfänger einmal mitnimmt.
Welches Problem Git eigentlich löst
Kennst du Ordner wie projekt_final, projekt_final_v2 und projekt_final_WIRKLICH_final? Genau dieses Chaos beendet Git. Statt Dateien zu kopieren und Datumsangaben an Namen zu hängen, speichert Git intelligente Schnappschüsse deines Projekts. Jeder Schnappschuss weiß, was sich geändert hat, wann und von wem.
Versionskontrolle löst drei konkrete Alltagsprobleme:
- Zeitreise: Du kannst jederzeit zu einem früheren Stand zurückspringen – auch noch nach Wochen.
- Sicherheit: Eine kaputte Änderung lässt sich rückgängig machen, ohne dass dein restlicher Code leidet.
- Zusammenarbeit: Mehrere Menschen arbeiten parallel an einem Projekt, und Git führt die Ergebnisse sauber zusammen.
Wichtig zu wissen: Git ist das Werkzeug auf deinem Computer. GitHub (oder GitLab, Bitbucket) ist nur ein Online-Speicherort dafür – wie Dropbox für Code. Du kannst Git komplett ohne Internet nutzen; das Online-Backup kommt erst beim Teilen ins Spiel.
Die vier Begriffe, die du verstehen musst
Bevor wir Befehle eintippen, klären wir die vier Wörter, die in jeder Git-Anleitung vorkommen. Verstehst du diese, verstehst du Git.
📦 Repository (Repo)
Das Repository ist dein Projektordner plus die komplette Versionshistorie. Sobald du git init ausführst, wird ein normaler Ordner zum Repo – Git legt darin einen versteckten .git-Ordner an, in dem die ganze Geschichte steckt.
📸 Commit
Ein Commit ist ein gespeicherter Schnappschuss zu einem bestimmten Zeitpunkt, immer mit einer kurzen Beschreibung („Login-Button hinzugefügt“). Du entscheidest selbst, wann ein Stand wichtig genug für einen Commit ist – das ist dein Sicherungspunkt.
🌿 Branch
Ein Branch (Zweig) ist eine parallele Arbeitslinie. Der Hauptzweig heißt meist main. Willst du ein Feature ausprobieren, ohne den funktionierenden Code zu gefährden, erstellst du einen eigenen Branch und experimentierst dort gefahrlos.
🔀 Merge
Merge bedeutet Zusammenführen. Ist dein Feature im Branch fertig, mergst du es zurück in main. Git kombiniert die Änderungen automatisch – nur wenn dieselbe Stelle doppelt geändert wurde, fragt es dich (ein „Merge-Konflikt“).
Die 7 wichtigsten Git-Befehle
Du brauchst zu Beginn nicht 100 Befehle, sondern genau diese sieben. Mit ihnen deckst du 90 % deines Alltags ab. Hier sind sie mit Zweck und einem Mini-Beispiel.
| Befehl | Was er macht | Beispiel |
|---|---|---|
git init | Macht aus dem aktuellen Ordner ein neues Git-Repository. | git init |
git status | Zeigt, welche Dateien geändert, neu oder bereit zum Commit sind. | git status |
git add | Wählt Änderungen für den nächsten Commit aus (legt sie in die „Staging Area“). | git add index.html |
git commit | Speichert die ausgewählten Änderungen als festen Schnappschuss mit Nachricht. | git commit -m "Startseite gebaut" |
git push | Lädt deine Commits ins Online-Repo (z. B. GitHub) hoch. | git push origin main |
git pull | Holt Änderungen anderer aus dem Online-Repo auf deinen Rechner. | git pull origin main |
git branch | Zeigt, erstellt oder löscht Branches (Arbeitszweige). | git branch feature-login |
Merk-Trick zur Reihenfolge: add wählt aus, commit speichert lokal, push schickt online. Stell dir einen Umzugskarton vor: add = Sachen reinlegen, commit = Karton zukleben und beschriften, push = Karton zum neuen Zuhause bringen.
Der typische Git-Workflow Schritt für Schritt
So sieht eine ganz normale Arbeitsrunde aus – vom leeren Ordner bis zum hochgeladenen Stand. Tipp die Befehle ruhig parallel mit.
- Repo anlegen: Im Projektordner führst du
git initaus. Ab jetzt beobachtet Git diesen Ordner. - Arbeiten: Du schreibst Code, erstellst Dateien, änderst etwas. Git hält sich noch raus – es merkt sich nur, dass sich etwas getan hat.
- Lage prüfen:
git statuszeigt dir alle geänderten Dateien in Rot. So siehst du genau, was Git bemerkt hat. - Auswählen: Mit
git add .nimmst du alle Änderungen für den nächsten Commit auf (der Punkt steht für „alles im Ordner“). - Committen:
git commit -m "Kurze Beschreibung"friert den Stand als festen Schnappschuss ein. - Hochladen: Mit
git pushwandert dein Commit ins Online-Repo – jetzt ist er gesichert und für andere sichtbar.
Als zusammenhängender Befehlsablauf für ein frisches Projekt sieht das so aus:
git init# alle Dateien für den Commit vormerken
git add .# Schnappschuss mit Nachricht speichern
git commit -m "Erster Commit: Projekt-Grundgerüst"# einmalig: Online-Repo verbinden
git remote add origin https://github.com/dein-name/projekt.git# hochladen und Branch dauerhaft verknüpfen
git push -u origin main
Nach diesem ersten push -u reicht künftig ein nacktes git push – Git merkt sich das Ziel.
Mit Branches sicher experimentieren
Hier wird Git richtig stark. Statt riskante Änderungen direkt in main zu machen, gibst du ihnen einen eigenen Zweig. Geht etwas schief, löschst du den Zweig einfach – main bleibt unberührt.
git switch -c feature-login# ... hier arbeitest, addest und committest du ...
# zurück zum Hauptzweig
git switch main# fertiges Feature zusammenführen
git merge feature-login
Der moderne Befehl zum Wechseln heißt git switch; in älteren Anleitungen liest du oft git checkout – beides funktioniert. Nach dem Merge kannst du den nicht mehr benötigten Branch mit git branch -d feature-login aufräumen.
.gitignore: Was Git ignorieren soll
Nicht alles gehört ins Repository. Passwörter, riesige Bibliotheks-Ordner oder automatisch erzeugte Dateien haben dort nichts verloren. Dafür legst du im Projektordner eine Datei namens .gitignore an und schreibst die zu ignorierenden Muster hinein – eine Zeile pro Eintrag.
node_modules/vendor/# Geheimnisse und Konfiguration
.env# System- und Editor-Müll
.DS_Store*.log
Achtung: Lege die .gitignore möglichst vor dem ersten Commit an. Hast du eine Datei schon einmal committet, ignoriert Git sie nicht rückwirkend – du musst sie dann erst mit git rm --cached dateiname aus der Verfolgung nehmen. Besonders .env-Dateien mit Passwörtern sollten nie versehentlich online landen.
Häufige Anfängerfehler – und wie du sie vermeidest
- Riesen-Commits: Wochenlang arbeiten und dann alles in einen Commit packen. Besser: kleine, oft. Jeder Commit sollte eine abgeschlossene Sache sein.
- Nichtssagende Nachrichten: „fix“, „update“, „asdf“ helfen später niemandem. Schreib, was du getan hast: „Validierung im Kontaktformular ergänzt“.
- Vor dem Push nicht pullen: Im Team arbeitest du nie allein. Hol dir mit
git pullerst die Änderungen anderer, bevor du pushst – sonst gibt es unnötige Konflikte. - Geheimnisse committen: API-Schlüssel oder
.env-Dateien rutschen schnell mit. Einmal online, gelten sie als kompromittiert. Die.gitignoreschützt dich. - Panik bei Konflikten: Ein Merge-Konflikt ist kein Fehler, sondern eine Rückfrage. Git markiert die betroffenen Stellen mit
<<<<<<<– du entscheidest, welche Version bleibt, speicherst und committest erneut.
⭐ Das Wichtigste in Kürze
- Git ist Versionskontrolle: jeder Stand wird gespeichert und ist wiederherstellbar.
- Vier Begriffe genügen:
Repo,Commit,Branch,Merge. - Dein Alltags-Trio:
git add→git commit -m→git push. - Eigene Branches schützen den funktionierenden Hauptzweig
main. - Eine
.gitignorehält Passwörter und Müll aus dem Repo heraus. - Commits klein halten und ehrlich beschreiben – dein zukünftiges Ich dankt dir.
Häufige Fragen
Was ist der Unterschied zwischen Git und GitHub?
Git ist das Versionskontroll-Programm, das auf deinem Computer läuft und die Historie deines Codes verwaltet. GitHub ist ein Online-Dienst, der diese Git-Repositories im Internet speichert und das Teilen sowie die Zusammenarbeit ermöglicht. Du kannst Git komplett ohne GitHub nutzen; GitHub ohne Git ergibt dagegen wenig Sinn.
Brauche ich für Git zwingend die Kommandozeile?
Nein, aber sie lohnt sich. Es gibt grafische Programme wie GitHub Desktop, Sourcetree oder die Git-Integration in VS Code, die alle Befehle per Klick anbieten. Trotzdem solltest du die sieben Grundbefehle kennen: Sie funktionieren überall gleich und du verstehst dann auch, was die grafischen Tools im Hintergrund tun.
Was bedeutet eigentlich „committen“?
Committen heißt, einen Schnappschuss deiner aktuell ausgewählten Änderungen dauerhaft in der Git-Historie zu speichern. Jeder Commit bekommt eine kurze Nachricht, die beschreibt, was geändert wurde. Du kannst später jederzeit zu jedem Commit zurückspringen – er ist dein gespeicherter Sicherungspunkt.
Wie mache ich eine Änderung rückgängig?
Solange du noch nicht committet hast, holt git restore dateiname den letzten gespeicherten Stand einer Datei zurück. Hast du bereits committet, erstellt git revert einen neuen Commit, der die Änderung sauber aufhebt – das ist im Team der sichere Weg. Den letzten Commit ganz lösen kannst du lokal mit git reset.
Wie lange dauert es, Git zu lernen?
Die Grundlagen für den Alltag – die sieben Befehle und der Workflow – sitzen meist nach ein bis zwei Tagen Übung. Fortgeschrittene Themen wie Rebase, Stash oder komplexe Merge-Strategien kommen nach und nach durch echte Projekte dazu. Wichtig ist nicht das Auswendiglernen, sondern das regelmäßige Anwenden.
Was ist ein Merge-Konflikt und ist er schlimm?
Ein Merge-Konflikt entsteht, wenn dieselbe Zeile in zwei Branches unterschiedlich geändert wurde und Git nicht selbst entscheiden kann, welche Version gilt. Das ist völlig normal und kein Drama. Git markiert die Stelle in der Datei, du wählst manuell die richtige Version aus, speicherst und committest. Danach ist der Konflikt gelöst.