Git Grundlagen – Versionskontrolle verstehen und effektiv nutzen

Git von Grund auf verstehen: Repository anlegen, Commits erstellen, Branches nutzen und mit Remote-Repos arbeiten. Der komplette Git-Einsteiger-Guide für Entwickler.

8 min Lesezeit

Git Grundlagen – Versionskontrolle verstehen und effektiv nutzen

Git ist das wichtigste Werkzeug in der modernen Softwareentwicklung. Ob Soloprojekt oder Team mit hundert Entwicklern – ohne Versionskontrolle ist professionelles Arbeiten kaum vorstellbar. Git protokolliert jede Änderung, ermöglicht das Parallel-Arbeiten an Features und macht Fehler rückgängig, ohne Daten zu verlieren.

Dieser Guide führt dich von der Installation bis zum souveränen Umgang mit Branches und Remote-Repositories.


Was ist Git – und warum brauche ich es?

Git ist ein verteiltes Versionskontrollsystem. Das bedeutet:

  • Jeder Entwickler hat eine vollständige Kopie des Repositories mit der gesamten History
  • Es gibt keine zentrale Abhängigkeit – du kannst lokal ohne Netzwerk arbeiten
  • Änderungen werden als "Commits" gespeichert – ein unveränderlicher Schnappschuss des Projektzustands

Ohne Git:

  • Ordner wie projekt_final_v2_WIRKLICH_FINAL.zip
  • Fehler, die nicht mehr rückgängig gemacht werden können
  • Zusammenarbeit per E-Mail mit manuellen Merge-Orgien

Mit Git:

  • Vollständige History jeder Änderung
  • Branches für Features ohne das Hauptprojekt zu gefährden
  • Pull Requests als strukturierter Review-Prozess
  • Rollback zu jedem beliebigen Zeitpunkt

Installation und Erstkonfiguration

Installation

# Ubuntu / Debian
sudo apt update && sudo apt install -y git

# Fedora
sudo dnf install -y git

# Version prüfen
git --version
# git version 2.53.0

Pflichteinstellung: Name und E-Mail

Git signiert jeden Commit mit Name und E-Mail. Diese Einstellung ist Pflicht vor dem ersten Commit:

# Global für alle Repositories
git config --global user.name "Dein Name"
git config --global user.email "deine@email.de"

# Standard-Branch auf 'main' setzen (moderner Standard)
git config --global init.defaultBranch main

# Bevorzugten Editor setzen (z.B. nano für Einsteiger, vim für Fortgeschrittene)
git config --global core.editor nano

Konfiguration prüfen

git config --list
# user.name=Dein Name
# user.email=deine@email.de
# init.defaultBranch=main

Die Konfiguration wird in ~/.gitconfig gespeichert:

cat ~/.gitconfig

Erstes Repository anlegen

Neues Repo erstellen

mkdir mein-projekt
cd mein-projekt
git init
# Initialized empty Git repository in /home/andre/mein-projekt/.git/

Bestehendes Repo klonen

# Von GitHub
git clone https://github.com/nutzer/repo.git

# Mit SSH (empfohlen, wenn SSH-Key eingerichtet ist)
git clone git@github.com:nutzer/repo.git

# In spezifischen Ordner klonen
git clone https://github.com/nutzer/repo.git mein-ordner

.gitignore – Was Git ignorieren soll

Fast jedes Projekt hat Dateien, die nicht ins Repository gehören: Abhängigkeiten, Secrets, Build-Artefakte.

# .gitignore im Projektroot erstellen
nano .gitignore

Beispiel für ein Python-Projekt:

# Virtuelle Umgebungen
.venv/
venv/
__pycache__/
*.pyc

# Secrets und Konfiguration
.env
*.key
*.pem

# IDE-Dateien
.vscode/
.idea/
*.swp

# Build-Artefakte
dist/
build/
*.egg-info/

Tipp: github.com/github/gitignore enthält vorgefertigte .gitignore-Templates für fast jede Sprache und Framework.


Der Git-Workflow: Stage → Commit → History

Der grundlegende Git-Zyklus besteht aus drei Schritten:

Arbeitsverzeichnis → Staging Area → Repository (History)
   (Änderungen)       (git add)      (git commit)

Status anzeigen

git status

Ausgabe-Bedeutung:

  • Untracked files – neue Dateien, die Git noch nicht kennt
  • Changes not staged – geänderte Dateien, noch nicht gestaged
  • Changes to be committed – gestaged, bereit für Commit

Änderungen stagen (git add)

# Einzelne Datei stagen
git add datei.txt

# Mehrere Dateien
git add datei1.txt datei2.py

# Ganzes Verzeichnis
git add src/

# Alle Änderungen stagen (Vorsicht: staged auch ungewollte Dateien!)
git add .

# Interaktiv stagen (zeilenweise)
git add -p datei.txt

Commit erstellen

# Commit mit Nachricht
git commit -m "Füge Login-Funktion hinzu"

# Staging und Commit in einem (nur für bereits getrackte Dateien)
git commit -am "Bugfix: Nullpointer in user.validate() behoben"

# Commit mit ausführlicher Nachricht (Editor öffnet sich)
git commit

Gute Commit-Messages:

# Format: kurze Zusammenfassung (max. 72 Zeichen), optional Leerzeile + Details

feat: Benutzer-Authentifizierung mit JWT implementiert

- Token-Ablaufzeit auf 24h gesetzt
- Refresh-Token-Mechanismus ergänzt
- Middleware für geschützte Routen hinzugefügt

Closes #42

Konvention: Conventional Commits (feat, fix, docs, style, refactor, test, chore)

History anzeigen

# Alle Commits (kompakt)
git log --oneline

# Mit Branching-Visualisierung
git log --oneline --graph --all

# Ausführliche Ansicht
git log

# Letzten 5 Commits
git log -5

# Änderungen eines Commits anzeigen
git show abc1234

# Wer hat welche Zeile zuletzt geändert?
git blame datei.txt

Änderungen ansehen (git diff)

# Unstaged Änderungen
git diff

# Staged Änderungen (was wird committet?)
git diff --staged

# Unterschied zwischen zwei Commits
git diff abc1234 def5678

# Unterschied zwischen Branches
git diff main feature/login

Branches: parallel arbeiten

Branches ermöglichen es, an Features zu arbeiten, ohne den Hauptzweig zu destabilisieren.

main ────●────────────────●────●── (stabil, produktionsreif)
          \              /
feature    ●────●────●──/ (Feature-Branch)

Branch-Grundlagen

# Alle Branches anzeigen
git branch
git branch -a   # auch Remote-Branches

# Neuen Branch erstellen
git branch feature/login

# Zum Branch wechseln (moderner Befehl: git switch, seit Git 2.23)
git switch feature/login

# Branch erstellen UND wechseln (ein Schritt)
git switch -c feature/login

# Alternativ (alter Befehl, noch weit verbreitet)
git checkout -b feature/login

# Branch löschen (nach dem Merge)
git branch -d feature/login

# Branch löschen erzwingen (auch ungemergt)
git branch -D feature/login

Branches zusammenführen (Merge)

# Zum Zielbranch wechseln
git switch main

# Feature-Branch mergen
git merge feature/login

# Merge mit explizitem Merge-Commit (kein Fast-Forward)
git merge --no-ff feature/login

Merge-Konflikte auflösen

Wenn zwei Branches dieselbe Zeile unterschiedlich geändert haben, entsteht ein Konflikt:

<<<<<<< HEAD (main)
const port = 3000;
=======
const port = 8080;
>>>>>>> feature/config

Auflösen:

  1. Datei öffnen und Konflikt-Markierungen manuell bearbeiten
  2. Gewünschten Code behalten, Markierungen entfernen
  3. Datei stagen: git add datei.js
  4. Merge abschließen: git commit
# Merge abbrechen und zum Ausgangszustand zurück
git merge --abort

Rebase (Alternative zu Merge)

Rebase schreibt die Commit-History um und fügt Commits an das Ende des Zielbranches an – sauberere History, aber vorsichtig bei shared Branches:

git switch feature/login
git rebase main

Faustregel: Merge für öffentliche/shared Branches. Rebase nur für lokale, noch nicht gepushte Branches.


Remote-Repositories: GitHub und GitLab

Remote hinzufügen

# Remote "origin" hinzufügen
git remote add origin git@github.com:dein-nutzer/repo.git

# Alle Remotes anzeigen
git remote -v

# Remote-URL ändern
git remote set-url origin git@github.com:dein-nutzer/neues-repo.git

Pushen und Pullen

# Ersten Push (Branch tracken)
git push -u origin main

# Danach reicht
git push

# Änderungen vom Remote holen
git pull

# Holen ohne Merge (nur herunterladen)
git fetch origin

# Nach fetch: lokalen Branch mit Remote-Stand zusammenführen
git merge origin/main

Typischer Workflow mit GitHub/GitLab

# 1. Feature-Branch erstellen
git switch -c feature/payment

# 2. Arbeiten, stagen, committen
git add .
git commit -m "feat: Stripe-Integration für Zahlungen"

# 3. Auf Remote pushen
git push -u origin feature/payment

# 4. Pull Request / Merge Request im Web erstellen
# → Review durch Kollegen → Merge → Branch löschen

# 5. Lokal aufräumen
git switch main
git pull
git branch -d feature/payment

Typische Workflows im Alltag

Letzten Commit korrigieren

# Commit-Nachricht ändern (nur wenn noch nicht gepusht!)
git commit --amend -m "Neue, bessere Commit-Message"

# Vergessene Datei zum letzten Commit hinzufügen
git add vergessen.txt
git commit --amend --no-edit

Änderungen temporär parken (git stash)

# Aktuelle Änderungen weglegen (ohne Commit)
git stash

# Gestashte Änderungen wiederherstellen
git stash pop

# Alle Stashes anzeigen
git stash list

# Spezifischen Stash anwenden
git stash apply stash@{0}

Dateien aus Staging entfernen

# Datei aus Staging nehmen (Änderung bleibt erhalten)
git restore --staged datei.txt

# Änderung einer Datei verwerfen (VORSICHT: unwiderruflich!)
git restore datei.txt

Zu einem älteren Commit zurück (Rollback)

# History anzeigen, Commit-Hash notieren
git log --oneline

# Datei aus altem Commit wiederherstellen
git restore --source abc1234 datei.txt

# Ganzes Repo zu altem Stand (als neuer Branch)
git switch -c recovery abc1234

Häufige Fehler und wie du sie behebst

„fatal: not a git repository"

# Prüfen ob .git-Verzeichnis existiert
ls -la | grep .git

# Falls nicht: Repository initialisieren
git init

Commit auf falschen Branch gemacht

# Commit vom aktuellen Branch entfernen, aber Änderungen behalten
git reset HEAD~1

# Zum richtigen Branch wechseln und dort committen
git switch richtiger-branch
git add .
git commit -m "..."

Datei versehentlich gelöscht

# Gelöschte Datei wiederherstellen
git restore datei.txt

Push wird abgelehnt (Remote ist weiter)

! [rejected] main -> main (fetch first)
# Remote-Änderungen erst holen und mergen
git pull --rebase
git push

Sensible Daten committet (Passwörter, API-Keys)

# Sofort: Datei aus letztem Commit entfernen
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "Remove .env from tracking"
git push

# Falls bereits auf Remote: API-Key sofort rotieren/invalidieren!
# Dann: git filter-repo nutzen (komplexer, separater Guide)

Die wichtigsten Git-Befehle im Überblick

# Setup
git config --global user.name "Name"
git config --global user.email "mail@beispiel.de"
git init
git clone <url>

# Status & History
git status
git log --oneline --graph --all
git diff [--staged]

# Stage & Commit
git add <datei>         # stagen
git add .               # alles stagen
git commit -m "msg"     # committen
git commit --amend      # letzten Commit ändern

# Branches
git branch              # anzeigen
git switch -c <branch>  # erstellen + wechseln
git merge <branch>      # mergen
git branch -d <branch>  # löschen

# Remote
git remote add origin <url>
git push -u origin main
git pull
git fetch

# Rückgängig machen
git restore <datei>           # Änderung verwerfen
git restore --staged <datei>  # aus Staging nehmen
git reset HEAD~1              # letzten Commit rückgängig (Änderungen bleiben)
git stash / git stash pop     # Änderungen parken

Fazit

Git ist keine Option, sondern Standard. Wer einmal den Workflow verinnerlicht hat – Stage, Commit, Push, Branch – arbeitet effizienter und sicherer. Die Lernkurve ist flach, der Nutzen ist enorm.

Nächste Schritte:


Git 2.53.0 | Tested on: Ubuntu 24.04 LTS, Debian 13 Trixie | Last updated: 2026-02-18

War dieser Artikel hilfreich?