Git workflow pour TypeScript : comment ne pas perdre la tête dans du code typé

Git workflow pour TypeScript : comment arrêter d'avoir peur des merge conflicts

Si vous avez déjà essayé de merger deux branches, où l'une modifiait l'interface User et l'autre ajoutait un nouveau type dans le même module, vous savez ce qu'est une crise existentielle de développeur. TypeScript nous offre un système de types puissant, mais sans un Git workflow approprié, cette puissance se transforme en casse-tête.

Dans cet article, nous allons détailler le Git workflow optimal pour les projets TypeScript — de la configuration des branches à la vérification automatique des types à chaque commit. Rien de superflu, seulement ce qui fonctionne vraiment en production.

Pourquoi TypeScript nécessite-t-il une approche particulière de Git ?

TypeScript n'est pas simplement « JavaScript avec des types ». C'est un langage où chaque modification peut impacter des dizaines de fichiers via interface, type et les génériques. Une seule modification erronée dans un type de base, et tout le projet cesse de se compiler.

C'est pourquoi un git workflow standard pour TypeScript doit inclure :

\n
• Une vérification obligatoire des types avant le commit
\n
• Un linter qui empêche de commiter du code non formaté
\n
• Une stratégie de branchement claire pour que les merge conflicts ne cassent pas les types
\n
• Un CI/CD qui revérifie tout sur le serveur
\n

Examinons chaque point dans l'ordre.

1. Choisir une stratégie de branchement : Git Flow ou Trunk-based ?

Pour les projets TypeScript, je recommande le Trunk-based development avec des branches à courte durée de vie. Pourquoi ? Parce que le code TypeScript est, par essence, du code « brut » qui doit être rapidement vérifié et déployé. Les branches longues entraînent une « divergence » des types.

Structure de base des branches

main        — version stable, toujours prête pour le déploiement\ndevelop     — branche principale de développement\nfeature/*   — nouvelles fonctionnalités (vivent 1-2 jours)\nfix/*       — corrections de bugs\nrelease/*   — préparation de version (optionnel)\n

Exemple pour un projet TypeScript :

git checkout -b feature/add-user-validation\n# on travaille...\ngit commit -m "feat: add email validation for User type"\ngit push origin feature/add-user-validation\n# on crée une PR → merge dans develop\n

Important : ne faites jamais de rebase sur main si le projet contient des types partagés. Utilisez merge — il préserve l'historique et ne casse pas les dépendances.

2. Git Hooks : protection contre les erreurs (et contre soi-même)

Le scénario le plus fréquent : vous oubliez de lancer tsc, vous commitez, vous pushez, et le CI échoue. Pour éviter cela, configurons des pre-commit hooks.

Installation de Husky + lint-staged

Husky est un outil de gestion des Git hooks. lint-staged exécute des commandes uniquement sur les fichiers modifiés.

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

Créez le fichier .husky/pre-commit :

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

Dans package.json, ajoutez :

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

Désormais, avant chaque commit :

\n
1. ESLint s'exécute avec correction automatique
\n
2. Le code est formaté via Prettier
\n
3. La compilation TypeScript est vérifiée (tsc --noEmit)
\n

Si une seule étape échoue — le commit est bloqué. Brutal, mais efficace.

3. Messages de commit corrects : conventional commits

Les projets TypeScript bénéficient des conventional commits, car :

\n
• Un changelog est généré automatiquement
\n
• Il est facile de comprendre quels changements cassent les types
\n
• On peut déclencher le CI uniquement sur certains commits
\n

Exemples :

feat: add UserRole enum and validation\nfix: c