Git workflow pour les développeurs Kotlin : comment ne pas casser le projet

Introduction : Pourquoi Git n'est pas seulement « git push »

Si vous codez en Kotlin, vous savez à quel point ce langage est agréable : concis, sûr, moderne. Mais même le code le plus élégant se transforme en chaos si l'équipe n'a pas de workflow Git clair. Avez-vous déjà essayé de fusionner une branche où un développeur a renommé la moitié des fichiers, un autre a refactoré les coroutines, et un troisième a accidentellement poussé `build.gradle.kts` avec des chemins locaux ?

Le Git workflow pour les développeurs Kotlin n'est pas qu'un ensemble de règles ennuyeuses. C'est votre bouclier contre les conflits, le garant d'un `main` stable et un moyen de ne pas passer votre lundi à démêler « qui a cassé quoi ». Dans cet article, nous allons décortiquer un pipeline réel : de la configuration de `.gitignore` pour Kotlin aux vérifications automatiques via Gradle et les hooks pre-commit.

C'est parti pour mettre de l'ordre dans votre dépôt !

1. Les bases : Configuration du dépôt pour Kotlin

1.1. Le bon .gitignore pour Kotlin

La première chose à faire est d'oublier le copier-coller de modèles depuis GitHub. Les projets Kotlin ont des dossiers spécifiques qui ne doivent pas entrer dans le dépôt. Voici un kit de base minimal :

# Kotlin & JVM\n*.class\n*.jar\n*.war\n*.ear\nbuild/\n!gradle/wrapper/gradle-wrapper.jar\n\n# IDE (IntelliJ IDEA)\n.idea/\n*.iml\n*.iws\nout/\n\n# OS\n.DS_Store\nThumbs.db\n\n# Gradle\n.gradle/\nlocal.properties\n

Notez que nous excluons explicitement `.idea/` – cela évitera à vos collègues des conflits dans les configurations de l'IDE. Et `local.properties` (chemin vers le SDK) est une chose purement locale.

1.2. Les hooks Git : votre linter personnel

Un Git workflow pour les développeurs Kotlin est impensable sans hooks pre-commit. Ils s'exécutent avant que le commit ne soit créé. L'outil le plus populaire est pre-commit avec des plugins pour Kotlin.

Exemple de configuration `.pre-commit-config.yaml` :

repos:\n  - repo: https://github.com/pre-commit/mirrors-ktlint\n    rev: v0.50.0\n    hooks:\n      - id: ktlint\n        args: ["--format"]\n\n  - repo: https://github.com/detekt/detekt\n    rev: v1.23.1\n    hooks:\n      - id: detekt\n

Désormais, avant chaque commit, `ktlint` formatera le code et `detekt` vérifiera les bogues potentiels. Fini les « j'ai oublié de lancer le linter » !

2. Stratégie de branchement : choisir son workflow

2.1. Git Flow — le classique pour les grands projets

Pour les monolithes Kotlin ou les projets avec des versions strictes, le classique Git Flow convient. Branches principales :

\n
• main — uniquement du code stable, en production.
\n
• develop — branche d'intégration pour le développement.
\n
• feature/* — chaque nouvelle fonctionnalité.
\n
• release/* — préparation de la version (correction de bugs, mise à jour de version).
\n
• hotfix/* — correctifs urgents en production.
\n

Exemple pour Kotlin : vous développez une nouvelle fonction de traitement des coroutines. Vous créez la branche feature/coroutine-flow, vous travaillez, puis vous fusionnez dans develop. Quand assez de fonctionnalités sont prêtes pour une version, vous créez release/2.1.0, vous y corrigez les bugs et ensuite seulement vous fusionnez dans main.

2.2. GitHub Flow — pour le CI/CD et les versions rapides

Si vous écrivez un microservice avec Ktor ou Spring Boot et que vous déployez tous les jours, Git Flow sera excessif. Utilisez GitHub Flow :

\n
• La branche main est toujours prête à être déployée.
\n
• Chaque tâche — feature/nom.
\n
• Après avoir terminé — Pull Request, revue de code, tests automatiques, fusion dans main.
\n
• Immédiatement après la fusion — déploiement (dans l'idéal).
\n

Idéal pour les projets Kotlin avec une bonne couverture de tests.

2.3. Trunk-based — pour les audacieux

Vous travaillez dans une startup ou sur un projet personnel ? Trunk-based (tout le monde commit dans main avec des commits courts) accélère le développement, mais nécessite une excellente discipline et des tests automatisés solides.