Git-Workflow für TypeScript: Wie man in typisiertem Code nicht den Verstand verliert

Git-Workflow für TypeScript: Wie man die Angst vor Merge-Konflikten verliert

Wenn Sie jemals versucht haben, zwei Branches zu mergen, wobei einer das Interface User geändert hat und der andere einen neuen Typ im selben Modul hinzugefügt hat, dann wissen Sie, was eine existenziellen Krise eines Entwicklers ist. TypeScript gibt uns ein mächtiges Typsystem, aber ohne den richtigen Git-Workflow wird diese Macht zum Kopfschmerz.

In diesem Artikel werden wir den optimalen Git-Workflow für TypeScript-Projekte durchgehen – von der Einrichtung der Branches bis zur automatischen Typprüfung bei jedem Commit. Kein Blabla, nur das, was im echten Einsatz wirklich funktioniert.

Warum TypeScript einen besonderen Ansatz für Git erfordert?

TypeScript ist nicht einfach „JavaScript mit Typen“. Es ist eine Sprache, bei der jede Änderung Dutzende von Dateien über interface, type und Generics betreffen kann. Eine einzige falsche Änderung an einem Basistyp – und das gesamte Projekt kompiliert nicht mehr.

Daher sollte ein standardmäßiger Git-Workflow für TypeScript Folgendes beinhalten:

\n
• Zwingende Typprüfung vor dem Commit
\n
• Einen Linter, der das Committen von unformatiertem Code verhindert
\n
• Eine klare Branching-Strategie, damit Merge-Konflikte keine Typen zerstören
\n
• CI/CD, das alles auf dem Server noch einmal überprüft
\n

Lassen Sie uns jeden Punkt der Reihe nach durchgehen.

1. Branching-Strategie wählen: Git Flow oder Trunk-based?

Für TypeScript-Projekte empfehle ich Trunk-based Development mit kurzlebigen Branches. Warum? Weil TypeScript-Code im Grunde „roher“ Code ist, der schnell überprüft und deployed werden muss. Lange Branches führen dazu, dass die Typen „auseinanderdriften“.

Basisstruktur der Branches

main        – stabile Version, immer bereit zum Deploy\ndevelop     – Hauptentwicklungsbranch\nfeature/*   – neue Features (leben 1-2 Tage)\nfix/*       – Bugfixes\nrelease/*   – Release-Vorbereitung (optional)\n

Beispiel für ein TypeScript-Projekt:

git checkout -b feature/add-user-validation\n# arbeiten...\ngit commit -m "feat: add email validation for User type"\ngit push origin feature/add-user-validation\n# PR erstellen → merge in develop\n

Wichtig: Führen Sie niemals einen Rebase auf main durch, wenn das Projekt gemeinsame Typen hat. Verwenden Sie Merge – er bewahrt die Historie und zerstört keine Abhängigkeiten.

2. Git Hooks: Schutz vor Dummheit (und vor sich selbst)

Das häufigste Szenario: Sie vergessen, tsc auszuführen, committen, pushen, und CI schlägt fehl. Um dies zu vermeiden, richten wir Pre-Commit-Hooks ein.

Installation von Husky + lint-staged

Husky ist ein Tool zur Verwaltung von Git Hooks. lint-staged führt Befehle nur auf geänderten Dateien aus.

npm install --save-dev husky lint-staged\nnpx husky init\n

Erstellen Sie die Datei .husky/pre-commit:

#!/usr/bin/env sh\n. "$(dirname -- "$0")/_/husky.sh"\n\nnpx lint-staged\n

In package.json fügen Sie hinzu:

{\n  "lint-staged": {\n    "*.ts": [\n      "eslint --fix",\n      "prettier --write",\n      "tsc --noEmit"\n    ]\n  }\n}\n

Jetzt wird vor jedem Commit:

\n
1. ESLint mit Autofix ausgeführt
\n
2. Code mit Prettier formatiert
\n
3. Die TypeScript-Kompilierung überprüft (tsc --noEmit)
\n

Wenn auch nur ein Schritt fehlschlägt – der Commit wird nicht durchgeführt. Hart, aber effektiv.

3. Korrekte Commit-Nachrichten: Conventional Commits

TypeScript-Projekte profitieren von Conventional Commits, weil:

\n
• Automatisch ein Changelog generiert wird
\n
• Leicht zu verstehen ist, welche Änderungen Typen zerstören
\n
• CI nur bei bestimmten Commits getriggert werden kann
\n

Beispiele:

feat: add UserRole enum and validation\nfix: c