Git - Lokale Versionskontrolle

Git installieren

macOS

Gute Nachrichten: Git ist wahrscheinlich schon da. Check im Terminal:

git --version

Kommt eine Versionsnummer? Dann bist du fertig. Falls nicht, fragt macOS automatisch, ob du die Command Line Tools installieren willst. Einfach bestätigen und warten.

Windows

Lade Git von git-scm.com herunter. Der Installer fragt viel - die Standardeinstellungen sind okay.

Linux

sudo apt update
sudo apt install git

Einmalige Konfiguration

Git will wissen, wer du bist. Das steht dann bei jedem Commit dabei:

git config --global user.name "Dein Name"
git config --global user.email "deine@email.com"

Das --global bedeutet: gilt für alle deine Projekte auf diesem Rechner.

Einstellungen prüfen

git config --list

Projekt mit Git verbinden

Repository initialisieren

Im Terminal in deinen Projektordner wechseln:

cd /pfad/zu/deinem/projekt

Dann Git aktivieren:

git init

Das war's. Git antwortet mit sowas wie "Initialized empty Git repository in...". Der versteckte .git-Ordner ist jetzt da.

Was jetzt NICHT passiert

Git trackt noch nichts automatisch! Es wartet darauf, dass du sagst, welche Dateien es beobachten soll. Das machst du mit deinem ersten Commit (kommt gleich).

Existierendes Repo kopieren

# Von GitHub oder anderem Server
git clone https://github.com/user/repo.git

# Lokales Repo kopieren (selten, aber möglich)
git clone /pfad/zum/original /pfad/zur/kopie

.gitignore - Was Git ignorieren soll

Bevor du anfängst zu committen: Sag Git, was es NICHT tracken soll. Dafür erstellst du eine .gitignore-Datei im Root deines Projekts.

Typische .gitignore für Webprojekte

# Dependencies - die werden über package.json neu installiert
node_modules/
package-lock.json

# Logs
*.log
npm-debug.log*

# OS-Dateien (die will niemand sehen)
.DS_Store
Thumbs.db

# Editor-Einstellungen (jeder hat seine eigenen)
.vscode/
.idea/
*.swp

# Persönliche Ordner
-noupload/
README/
temp/

Wie die Syntax funktioniert

• datei.txt - Diese eine Datei ignorieren
• ordner/ - Kompletter Ordner (der Slash am Ende = "ist ein Verzeichnis")
• *.log - Alle Dateien mit dieser Endung
• # Kommentar - Wird ignoriert, nur für dich zur Orientierung

Warum das wichtig ist

Der node_modules-Ordner kann hunderte MB groß sein. Den willst du nicht in deiner Git-Historie haben. Außerdem kann jeder ihn mit npm install neu generieren - dafür ist ja die package.json da.

touch uploads/.gitkeep
git add uploads/.gitkeep

Die drei Zustände verstehen

Das ist der Teil, der am Anfang verwirrend ist. Git hat drei "Bereiche":

1. Working Directory

Das ist einfach dein Projektordner. Hier arbeitest du ganz normal an deinen Dateien.

2. Staging Area

Ein Zwischenbereich. Hier sammelst du Änderungen, die zusammen in den nächsten Commit sollen. Wie ein Einkaufskorb - du legst rein, was du "kaufen" (committen) willst.

3. Repository

Die permanente Git-Datenbank im .git-Ordner. Hier landen die Commits.

Der Ablauf

# 1. Du änderst eine Datei (Working Directory)
# 2. Du sagst "die soll in den nächsten Commit"
git add datei.html

# 3. Du machst den Commit (speicherst den Snapshot)
git commit -m "Navigation überarbeitet"

Warum nicht direkt committen?

Die Staging Area gibt dir Kontrolle. Du kannst 10 Dateien geändert haben, aber nur 3 davon committen. So bleiben deine Commits thematisch sauber.

Status checken

Der wichtigste Befehl, den du ständig nutzen wirst:

git status

Was du siehst

• Rot = Geändert, aber noch nicht staged
• Grün = Staged, bereit für Commit
• "Untracked files" = Neue Dateien, die Git noch nie gesehen hat

Beispiel-Output

On branch main
Changes not staged for commit:
  modified:   css/style.css
  modified:   index.html

Untracked files:
  js/new-feature.js

Das heißt: Du hast style.css und index.html geändert (aber noch nicht staged), und new-feature.js ist komplett neu.

Änderungen stagen

Mit git add sagst du: "Diese Änderung soll in den nächsten Commit."

Verschiedene Wege

# Eine einzelne Datei
git add index.html

# Mehrere Dateien
git add index.html css/style.css

# Alle Änderungen im aktuellen Ordner
git add .

# Alle Änderungen im gesamten Projekt
git add -A

Was ist der Unterschied zwischen . und -A?

git add . staged alles im aktuellen Verzeichnis und darunter. git add -A staged wirklich ALLES, egal wo du gerade im Terminal bist. Meistens macht das keinen Unterschied, wenn du im Root-Ordner bist.

Staging rückgängig machen

Ups, doch nicht? Kein Problem:

git restore --staged datei.html

Die Datei ist wieder "unstaged", aber deine Änderungen bleiben erhalten.

Commits machen

Ein Commit ist ein Snapshot deines Projekts. Der Befehl:

git commit -m "Deine Nachricht hier"

Das -m steht für "message". Die Nachricht beschreibt, was du geändert hast.

Gute vs. schlechte Commit-Nachrichten

# Schlecht - sagt nichts aus
git commit -m "Update"
git commit -m "Fix"
git commit -m "Stuff"

# Gut - man versteht sofort was passiert ist
git commit -m "Header: Mobile Navigation hinzugefügt"
git commit -m "Bugfix: Footer bleibt jetzt unten"
git commit -m "SEO: Meta-Descriptions ergänzt"

Stell dir vor, du schaust in 6 Monaten auf die Historie. "Update" hilft dir null. "Header: Mobile Navigation hinzugefügt" sagt dir sofort, worum es geht. Hier gibt es eine kleine Übersicht der Conventional Commits.

Shortcut für Faule

git commit -am "Nachricht"

Das -a staged automatisch alle geänderten (bereits getrackten) Dateien. Funktioniert aber NICHT für neue Dateien!

Erster Commit eines Projekts

git add -A
git commit -m "Initial commit"

"Initial commit" ist die übliche Nachricht für den allerersten Commit.

Änderungen ansehen

Was hab ich geändert?

git diff

Zeigt alle Änderungen, die noch nicht staged sind. Zeilen mit - wurden entfernt, mit + hinzugefügt.

Was ist staged?

git diff --staged

Zeigt, was in den nächsten Commit gehen würde.

Nur Dateinamen

git diff --name-only

Wenn du nur wissen willst, welche Dateien betroffen sind.

Historie anschauen

Commit-Log

git log

Zeigt alle Commits mit Hash, Autor, Datum und Nachricht. Mit q kommst du wieder raus.

Kompakte Ansicht

git log --oneline

Viel übersichtlicher - eine Zeile pro Commit:

a1b2c3d Header: Mobile Navigation
e4f5g6h Bugfix: Footer Position
i7j8k9l Initial commit

Die komische Zeichenfolge am Anfang (a1b2c3d) ist der Commit-Hash - eine eindeutige ID.

Letzte X Commits

git log -5

Zeigt nur die letzten 5 Commits.

Historie einer Datei

git log -- css/style.css

Zeigt nur Commits, die diese Datei betreffen.

Änderungen rückgängig machen

Änderungen verwerfen (VORSICHT!)

git restore datei.html

Setzt die Datei auf den letzten Commit zurück. Deine Änderungen sind dann WEG. Wirklich weg. Kein Papierkorb.

Letzten Commit korrigieren

Tippfehler in der Commit-Nachricht?

git commit --amend -m "Richtige Nachricht"

Datei vergessen?

git add vergessene-datei.html
git commit --amend --no-edit

--no-edit behält die ursprüngliche Nachricht.

Commit rückgängig machen

git revert abc123

Erstellt einen neuen Commit, der die Änderungen von abc123 rückgängig macht. Die Historie bleibt intakt.

Zurück zu einem älteren Zustand

# Soft: Änderungen bleiben staged
git reset --soft HEAD~1

# Mixed: Änderungen bleiben, aber unstaged
git reset HEAD~1

# Hard: ALLES weg (GEFÄHRLICH!)
git reset --hard HEAD~1

HEAD~1 bedeutet "ein Commit zurück". HEAD~3 wäre drei zurück.

Branches - Parallele Welten

Branches sind wie parallele Zeitlinien. Du kannst an einem Feature arbeiten, ohne den Hauptcode zu berühren.

git branch

git branch feature-suche

git checkout feature-suche

git checkout -b feature-suche

Typischer Workflow

# 1. Neues Feature starten
git checkout -b feature-suche

# 2. Arbeiten, committen...
git add .
git commit -m "Suchfeld im Header"
git commit -m "Suchergebnisse anzeigen"

# 3. Zurück zum Hauptbranch
git checkout main

# 4. Feature integrieren
git merge feature-suche

# 5. Branch löschen (optional)
git branch -d feature-suche

Branch löschen

# Nur wenn gemerged
git branch -d feature-suche

# Erzwingen (auch wenn nicht gemerged)
git branch -D feature-suche

Merge-Konflikte

Manchmal haben beide Branches die gleiche Stelle geändert. Git markiert das so:

<<<<<<< HEAD
Deine Version
=======
Die andere Version
>>>>>>> feature-suche

Du musst manuell entscheiden, welche Version richtig ist. Lösch die Marker <<<, ===, >>>, behalte den Code den du willst, dann:

git add die-datei.html
git commit -m "Merge-Konflikt gelöst"

# Statt: git checkout feature-suche
git switch feature-suche

# Statt: git checkout -b feature-suche
git switch -c feature-suche

Stashing - Änderungen parken

Du arbeitest an etwas, musst aber schnell was anderes machen? Stash parkt deine Änderungen temporär.

git stash

git stash save "Angefangene Navigation"

Stash wiederholen

# Anwenden und behalten
git stash apply

# Anwenden und löschen
git stash pop

Alle Stashes anzeigen

git stash list

Stash löschen

# Einen bestimmten
git stash drop stash@{0}

# Alle
git stash clear

Tags - Versionen markieren

Tags sind Lesezeichen für wichtige Commits, typischerweise Releases.

Tag erstellen

# Einfacher Tag
git tag v1.0.0

# Mit Beschreibung (empfohlen)
git tag -a v1.0.0 -m "Erste stabile Version"

git tag

git tag -d v1.0.0

Zu Tag wechseln

git checkout v1.0.0

Du bist dann im "detached HEAD" Zustand - quasi nur zum Anschauen.

Git Cheatsheet

Setup

git config --global user.name "Name"
git config --global user.email "email"
git init

Tägliche Arbeit

git status              # Was ist los?
git add .               # Alles stagen
git commit -m "Text"    # Committen
git log --oneline       # Historie

Änderungen

git diff                # Was hab ich geändert?
git restore datei       # Änderungen verwerfen
git restore --staged d  # Unstagen

Branches

git branch              # Branches anzeigen
git checkout -b name    # Neuer Branch
git checkout main       # Wechseln
git merge name          # Zusammenführen
git branch -d name      # Löschen

Rückgängig

git commit --amend      # Letzten Commit ändern
git revert hash         # Commit rückgängig
git stash               # Zwischenspeichern
git stash pop           # Wiederherstellen

Häufige Probleme

Datei wird trotz .gitignore getrackt

Die Datei war schon getrackt, bevor du sie zur .gitignore hinzugefügt hast:

git rm --cached datei.html
git commit -m "Datei aus Tracking entfernt"

Alles kaputt, zurück zum Start

# Zum letzten Commit zurück (LÖSCHT ÄNDERUNGEN!)
git reset --hard HEAD

# Zu bestimmtem Commit
git log --oneline  # Hash finden
git reset --hard abc123

Was hab ich eigentlich gemacht?

git reflog

Zeigt ALLES was du gemacht hast - auch "gelöschte" Commits. Lebensretter!

Best Practices

Commit-Häufigkeit

Lieber zu oft als zu selten. Ein Commit pro logischer Änderung ist ideal. "Header fertig" ist ein Commit. "Komplette Website redesigned" sind 20 Commits.

Commit-Nachrichten

Kurz, aber aussagekräftig. Was wurde geändert? Nicht wie oder warum - das steht im Code.

.gitignore von Anfang an

Erstell die .gitignore BEVOR du den ersten Commit machst. Dann landet kein Müll in der Historie.

Branches nutzen

Sobald du an etwas Experimentellem arbeitest: neuer Branch. Funktioniert es? Merge. Funktioniert es nicht? Branch löschen. Dein main-Branch bleibt sauber.

Regelmäßig Status checken

git status ist dein Freund. Vor jedem Commit, nach jedem Commit, zwischendurch. Es zeigt dir immer, wo du stehst.

Conventional Commits

Nächste Schritte

Du hast jetzt alles, was du für lokale Versionskontrolle brauchst. Git läuft komplett auf deinem Rechner, ohne Internet, ohne Account, ohne alles.

Wenn du dein Projekt online stellen, mit anderen teilen oder ein Backup in der Cloud haben willst, schau dir das GitHub Tutorial an. Aber das ist optional - Git funktioniert auch prima ohne.

Zum Üben

1. Initialisiere Git in einem Testprojekt
2. Erstell eine .gitignore
3. Mach deinen ersten Commit
4. Ändere was und committe wieder
5. Schau dir die Historie an
6. Erstell einen Branch und merge ihn

Nach ein paar Tagen wird git add + git commit so automatisch wie Speichern.