Git unter WSL 2: Performance-Tuning & Best Practices

Dieser Artikel ist Teil unserer Serie zur modernen WSL 2 Webentwicklung.

Git ist das Herzstück fast jeder modernen Entwicklungsumgebung. Unter einem reinen Linux oder Mac funktioniert es meist "out of the box". Doch bei der Arbeit mit Git unter WSL 2 bewegen wir uns in einer Hybrid-Umgebung.

Das führt oft zu frustrierenden Momenten: Du tippst git status und wartest. Und wartest. Oder du pushst Code, und plötzlich sind alle Zeilenumbrüche kaputt. Dieser Artikel basiert auf realen Projekten mit WSL 2, Git und VS Code. Wir dokumentieren typische Fehlerquellen und zeigen dir die bewährten Lösungen aus dem täglichen Entwickleralltag.

1. Git unter WSL 2: Die Performance-Falle

Viele Entwickler gehen anfangs davon aus, dass Git unter WSL 2 unabhängig vom Speicherort gleich schnell arbeitet. In der Praxis ist genau das Gegenteil der Fall. Git führt extrem viele kleine Datei-Operationen aus (Lesen, Hashen, Vergleichen) – und diese reagieren empfindlich auf das zugrunde liegende Dateisystem.

Warum Git-Repositories ins Linux-Home gehören

Repositories auf C:\ (also unter /mnt/c) zu verwalten, wirkt bequem, kostet aber massiv Leistung. Der Grund ist das von WSL 2 genutzte 9P-Protokoll, das jede Anfrage von Linux nach Windows übersetzen muss.

Der Realitäts-Vergleich:

Hier siehst du den direkten Unterschied zwischen der Ablage auf der Windows-Partition und dem nativen Linux-Dateisystem:

• Befehl: git status (in einem großen Repo)

  • Repo auf Windows (/mnt/c): ~4 - 8 Sekunden (spürbar träge)

  • Repo in WSL (~/projects): < 0.1 Sekunden (sofort)

• Befehl: git clone

  • Repo auf Windows (/mnt/c): Dauert oft Minuten

  • Repo in WSL (~/projects): Erledigt in Sekunden

• Befehl: npm install

  • Repo auf Windows (/mnt/c): Kaffeepause nötig

  • Repo in WSL (~/projects): Rasend schnell

Die goldene Regel für Git unter WSL 2: Alles, was Code ist, gehört ins Linux-Dateisystem.

# Richtiges Vorgehen:
cd ~
mkdir -p projects
cd projects
git clone git@github.com:mein-user/mein-projekt.git

2. Zeilenenden verstehen: LF vs. CRLF

Gemischte Teams mit Windows-, macOS- und Linux-Systemen stoßen früher oder später auf das klassische Zeilenenden-Problem.

• Windows nutzt CRLF (Carriage Return + Line Feed).

• Linux/WSL nutzt LF (Line Feed).

Wenn du Git unter WSL 2 nutzt, arbeitest du technisch auf Linux. Wenn dein Kollege auf reinem Windows arbeitet, kann ein einziger Commit alle Zeilen einer Datei als "geändert" markieren, nur weil sich das Zeilenende geändert hat.

Die Lösung: .gitattributes

Verlasse dich nicht auf globale Einstellungen, die jeder Entwickler anders hat. Lege eine .gitattributes Datei in das Wurzelverzeichnis deines Projekts.

Praxis-Beispiel (Copy & Paste):

1# .gitattributes
2# Erzwinge LF als Standard für das Repo (macht Git glücklich)
3* text=auto eol=lf
4
5# Spezifische Dateien explizit definieren
6*.js text eol=lf
7*.ts text eol=lf
8*.json text eol=lf
9*.php text eol=lf
10*.css text eol=lf
11*.html text eol=lf
12*.md text eol=lf
13
14# Binärdateien schützen (Wichtig!)
15*.png binary
16*.jpg binary

Damit zwingst du Git unter WSL 2 (und auch deine Windows-Kollegen), konsistente Zeilenenden zu nutzen.

3. Git-Credentials sicher verwalten (Nie wieder Passwörter tippen)

Wie authentifizierst du dich gegenüber GitHub oder GitLab? Hier gibt es zwei Wege, die unter WSL 2 besonders gut funktionieren.

Option A: Den Windows Git Credential Manager nutzen (HTTPS)

Das ist der "Magie-Trick". Du kannst Git unter WSL 2 anweisen, den Credential Manager von Windows zu nutzen. Vorteil: Du loggst dich einmal unter Windows ein (oft via Browser/2FA), und WSL darf diesen Login mitnutzen.

Führe diesen Befehl in deinem WSL-Terminal aus:

git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"

(Hinweis: Der Pfad kann je nach Git-Installation variieren, dies ist der Standard für Git for Windows).

Option B: SSH-Keys (Der Profi-Weg)

Der klassische Linux-Weg ist SSH – modern, sicher und unabhängig vom Betriebssystem. Ich empfehle heute den Ed25519 Standard, da er sicherer und performanter als alte RSA-Keys ist.

Key generieren:

ssh-keygen -t ed25519 -C "deine@email.com"
# Drücke Enter für Standardpfad.
# Setze eine Passphrase für Sicherheit!

Key anzeigen und kopieren:

cat ~/.ssh/id_ed25519.pub

Diesen String fügst du bei GitHub/GitLab unter "SSH Keys" ein.

Praxis-Tipp gegen nervige Passphrase-Eingabe: Damit du bei Git unter WSL 2 nicht bei jedem Push das Passwort eingeben musst, nutze den ssh-agent. Füge folgendes in deine ~/.bashrc oder ~/.zshrc ein, um den Agent beim Start zu laden:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

4. VS Code & Git: Ein perfektes Team

Wenn du ein Projekt über WSL Remote öffnest (code .), integriert sich VS Code nahtlos. Es nutzt automatisch:

• Die Git-Installation deiner Linux-Distro.

• Die korrekten Linux-Dateipfade.

• Deine SSH-Keys aus der WSL.

Empfehlenswerte Erweiterungen: Installiere diese Extensions im "WSL: Ubuntu" Kontext:

1. GitLens: Der Standard. Zeigt dir, wer wann welche Zeile geändert hat ("Blame").

2. Git Graph: Eine visuelle Darstellung deiner Branches und Merges, direkt in VS Code.

5. Produktivitäts-Hack: Git Aliases

Wer viel mit Git unter WSL 2 arbeitet, will nicht ständig git checkout tippen. Da wir uns in einer echten Linux-Shell befinden, können wir Aliases nutzen.

Füge diese Abkürzungen in deine ~/.gitconfig ein:

[alias]
    co = checkout
    ci = commit
    st = status
    br = branch
    hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
    oops = commit --amend --no-edit

Das Ergebnis:

• Statt git status tippst du nur noch git st.

• Statt git commit --amend --no-edit (um den letzten Commit schnell zu fixen) tippst du git oops.

Häufige Probleme mit Git unter WSL 2

Selbst beim besten Setup kann es haken. Hier sind die Lösungen für die 90%-Fälle.

Problem: Git reagiert extrem träge. Ursache: Dein Repository liegt sehr wahrscheinlich unter /mnt/c/Users/.... Lösung: Verschiebe es nach ~/projects (Linux Dateisystem).

Problem: Jeder Commit zeigt riesige Änderungen, obwohl ich kaum etwas gemacht habe. Ursache: LF vs. CRLF Konflikt. Lösung: Implementiere die .gitattributes Datei (siehe oben) und führe einmalig git add --renormalize . aus.

Problem: "Dubious ownership in repository" Fehler. Ursache: Du greifst mit Git unter WSL 2 auf eine Datei zu, die einem Windows-User gehört. Lösung: Füge das Verzeichnis zur Safe-List hinzu (Git sagt dir im Fehler meist genau, welchen Befehl du tippen musst): git config --global --add safe.directory /pfad/zum/repo

Problem: VS Code fragt ständig nach SSH Passphrase. Ursache: VS Code hat keinen Zugriff auf deinen SSH-Agent. Lösung: Starte VS Code immer aus dem Terminal (code .), in dem der Agent bereits läuft, oder nutze Keys ohne Passphrase (weniger sicher).

Fazit: Native Power mit Windows-Komfort

Mit diesem Setup ist die Basis für Git unter WSL 2 sauber gelegt. Du hast die Geschwindigkeit von Linux, die Sicherheit von SSH und den Komfort von VS Code unter Windows.

Die wichtigsten Regeln zusammengefasst:

1. Code gehört ins Linux-Dateisystem (~/projects).

2. Nutze .gitattributes für saubere Zeilenenden.

3. Verwende den Credential Manager oder SSH-Keys.