Flujo de trabajo Git para desarrolladores Kotlin: cómo no arruinar el proyecto

Introducción: Por qué Git no es solo «git push»

Si programas en Kotlin, sabes lo agradable que es este lenguaje: conciso, seguro, moderno. Pero incluso el código más elegante se convierte en caos si el equipo no tiene un flujo de trabajo Git claro. ¿Alguna vez has intentado fusionar una rama donde un desarrollador renombró la mitad de los archivos, otro refactorizó las corrutinas y un tercero subió accidentalmente `build.gradle.kts` con rutas locales?

El flujo de trabajo Git para desarrolladores Kotlin no son solo reglas aburridas. Es tu escudo contra conflictos, la garantía de un `main` estable y una forma de no perder el lunes desenredando «quién rompió qué». En este artículo, analizaremos un pipeline real: desde la configuración de `.gitignore` para Kotlin hasta verificaciones automáticas con Gradle y pre-commit hooks.

¡Vamos a poner orden en el repositorio!

1. Base: Configuración del repositorio para Kotlin

1.1. El .gitignore correcto para Kotlin

Lo primero que todos deben hacer es olvidarse de copiar y pegar plantillas de GitHub. En los proyectos Kotlin hay carpetas específicas que no deben ir al repositorio. Aquí tienes el conjunto mínimo indispensable:

# 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

Nota: excluimos explícitamente `.idea/` — esto evitará conflictos en las configuraciones del IDE entre colegas. Y `local.properties` (ruta al SDK) es algo puramente local.

1.2. Git hooks: tu linter personal

El flujo de trabajo Git para desarrolladores Kotlin es impensable sin pre-commit hooks. Se ejecutan antes de que se cree el commit. La herramienta más popular es pre-commit con plugins para Kotlin.

Ejemplo de configuración `.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

Ahora, antes de cada commit, `ktlint` formateará el código y `detekt` verificará posibles errores. ¡Se acabó el «olvidé ejecutar el linter»!

2. Estrategia de ramificación: elige tu flujo de trabajo

2.1. Git Flow — clásico para proyectos grandes

Para monolitos Kotlin o proyectos con lanzamientos estrictos, el clásico Git Flow es adecuado. Ramas principales:

\n
• main — solo código estable que está en producción.
\n
• develop — rama de integración para el desarrollo.
\n
• feature/* — cada nueva funcionalidad.
\n
• release/* — preparación para el lanzamiento (corrección de errores, actualización de versión).
\n
• hotfix/* — correcciones urgentes en producción.
\n

Ejemplo para Kotlin: estás desarrollando una nueva función de procesamiento de corrutinas. Creas la rama feature/coroutine-flow, trabajas, luego fusionas en develop. Cuando tienes suficientes funciones para un lanzamiento, creas release/2.1.0, corriges errores allí y solo entonces fusionas en main.

2.2. GitHub Flow — para CI/CD y lanzamientos rápidos

Si escribes un microservicio en Ktor o Spring Boot y despliegas a diario, Git Flow será excesivo. Usa GitHub Flow:

\n
• La rama main siempre está lista para desplegar.
\n
• Cada tarea — feature/nombre.
\n
• Al finalizar — Pull Request, revisión de código, pruebas automáticas, fusión en main.
\n
• Inmediatamente después de la fusión — despliegue (idealmente).
\n

Perfecto para proyectos Kotlin con buena cobertura de pruebas.

2.3. Trunk-based — para los audaces

¿Trabajas en una startup o haces un proyecto personal? Trunk-based (todos hacen commits en main con commits cortos) acelera el desarrollo, pero re