Git-Workflow für Kotlin-Entwickler: Wie man das Projekt nicht kaputt macht

Einleitung: Warum Git mehr ist als nur „git push“

Wenn Sie in Kotlin programmieren, wissen Sie, wie angenehm diese Sprache ist: prägnant, sicher, modern. Aber selbst der eleganteste Code wird zum Chaos, wenn das Team keinen klaren Git-Workflow hat. Haben Sie schon einmal versucht, einen Branch zu mergen, bei dem ein Entwickler die Hälfte der Dateien umbenannt, ein anderer die Coroutinen refaktorisiert und ein Dritter versehentlich die `build.gradle.kts` mit lokalen Pfaden hochgeladen hat?

Ein Git-Workflow für Kotlin-Entwickler ist nicht nur eine langweilige Regel. Er ist Ihr Schutzschild vor Konflikten, Garant für einen stabilen `main`-Branch und die Möglichkeit, den Montag nicht mit der Analyse „wer was kaputt gemacht hat“ zu verbringen. In diesem Artikel analysieren wir eine echte Pipeline: von der Einrichtung der `.gitignore` für Kotlin bis hin zu automatischen Checks mit Gradle und Pre-Commit-Hooks.

Bringen wir Ordnung in Ihr Repository!

1. Grundlagen: Repository-Einrichtung für Kotlin

1.1. Die richtige .gitignore für Kotlin

Das Erste, was jeder tun sollte: Vergessen Sie das Kopieren von Vorlagen von GitHub. In Kotlin-Projekten gibt es spezifische Ordner, die nicht in das Repository gelangen sollten. Hier ist ein minimaler, aber vollständiger Satz:

# 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

Beachten Sie: Wir schließen `.idea/` explizit aus – das erspart Kollegen Konflikte in den IDE-Konfigurationen. Und `local.properties` (Pfad zum SDK) ist eine rein lokale Angelegenheit.

1.2. Git-Hooks: Ihr persönlicher Linter

Ein Git-Workflow für Kotlin-Entwickler ist ohne Pre-Commit-Hooks undenkbar. Sie werden ausgeführt, bevor ein Commit erstellt wird. Das beliebteste Tool ist pre-commit mit Plugins für Kotlin.

Beispiel für die Konfiguration `.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

Jetzt formatiert `ktlint` vor jedem Commit den Code und `detekt` prüft auf potenzielle Fehler. Schluss mit „Ich habe vergessen, den Linter laufen zu lassen“!

2. Branching-Strategie: Wählen Sie Ihren Workflow

2.1. Git Flow – Klassiker für große Projekte

Für Kotlin-Monolithen oder Projekte mit strengen Releases eignet sich der klassische Git Flow. Hauptbranches:

\n
• main – nur stabiler Code, der in Produktion ist.
\n
• develop – Integrationsbranch für die Entwicklung.
\n
• feature/* – jede neue Funktion.
\n
• release/* – Vorbereitung auf das Release (Fehlerbehebung, Versionsaktualisierung).
\n
• hotfix/* – dringende Korrekturen in der Produktion.
\n

Beispiel für Kotlin: Sie entwickeln eine neue Funktion zur Verarbeitung von Coroutinen. Sie erstellen den Branch feature/coroutine-flow, arbeiten daran und mergen ihn dann in develop. Wenn genügend Funktionen für ein Release vorhanden sind, erstellen Sie release/2.1.0, beheben dort Fehler und mergen erst dann in main.

2.2. GitHub Flow – für CI/CD und schnelle Releases

Wenn Sie einen Mikroservice mit Ktor oder Spring Boot schreiben und täglich ausrollen, ist Git Flow zu viel. Verwenden Sie GitHub Flow:

\n
• Der Branch main ist immer bereit für das Deployment.
\n
• Jede Aufgabe – feature/Name.
\n
• Nach Abschluss: Pull Request, Code-Review, automatische Tests, Merge in main.
\n
• Direkt nach dem Merge: Deployment (idealerweise).
\n

Perfekt geeignet für Kotlin-Projekte mit guter Testabdeckung.

2.3. Trunk-based – für Mutige

Arbeiten Sie in einem Startup oder an einem Pet-Projekt? Trunk-based (alle committen mit kurzen Commits in main) beschleunigt die Entwicklung, erfordert aber