Fluxo de trabalho Git para desenvolvedores Kotlin: como não quebrar o projeto

Introdução: Por que Git não é apenas "git push"

Se você programa em Kotlin, sabe como essa linguagem é agradável: concisa, segura, moderna. Mas mesmo o código mais elegante se transforma em caos se a equipe não tiver um fluxo de trabalho Git claro. Você já tentou fazer merge de uma branch onde um desenvolvedor renomeou metade dos arquivos, outro refatorou as corrotinas e um terceiro acidentalmente enviou o `build.gradle.kts` com caminhos locais?

O fluxo de trabalho Git para desenvolvedores Kotlin não são apenas regras chatas. É seu escudo contra conflitos, garantia de um `main` estável e uma forma de não gastar a segunda-feira desvendando "quem quebrou o quê". Neste artigo, vamos analisar um pipeline real: desde a configuração do `.gitignore` para Kotlin até verificações automáticas com Gradle e pre-commit hooks.

Vamos organizar o repositório!

1. Base: Configuração do repositório para Kotlin

1.1. O .gitignore correto para Kotlin

A primeira coisa que todos devem fazer é esquecer o copiar e colar de templates do GitHub. Em projetos Kotlin, existem pastas específicas que não devem ir para o repositório. Aqui está um conjunto mínimo essencial:

# 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

Observe: excluímos explicitamente `.idea/` — isso salvará seus colegas de conflitos nas configurações da IDE. E `local.properties` (caminho para o SDK) é algo estritamente local.

1.2. Git hooks: seu linter pessoal

O fluxo de trabalho Git para desenvolvedores Kotlin é impensável sem pre-commit hooks. Eles são executados antes do commit ser criado. A ferramenta mais popular é o pre-commit com plugins para Kotlin.

Exemplo de configuração `.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

Agora, antes de cada commit, o `ktlint` formatará o código e o `detekt` verificará possíveis bugs. Chega de "esqueci de rodar o linter"!

2. Estratégia de ramificação: escolhendo seu workflow

2.1. Git Flow — clássico para projetos grandes

Para monolítos Kotlin ou projetos com lançamentos rígidos, o clássico Git Flow é adequado. Branches principais:

\n
• main — apenas código estável que está em produção.
\n
• develop — branch de integração para desenvolvimento.
\n
• feature/* — cada nova funcionalidade.
\n
• release/* — preparação para o lançamento (correção de bugs, atualização de versão).
\n
• hotfix/* — correções urgentes em produção.
\n

Exemplo para Kotlin: você está desenvolvendo uma nova função de processamento de corrotinas. Cria a branch feature/coroutine-flow, trabalha nela, depois faz merge em develop. Quando houver funcionalidades suficientes para um lançamento, cria release/2.1.0, corrige bugs lá e só então faz merge em main.

2.2. GitHub Flow — para CI/CD e lançamentos rápidos

Se você escreve um microsserviço em Ktor ou Spring Boot e faz deploys diariamente, o Git Flow será exagerado. Use o GitHub Flow:

\n
• A branch main está sempre pronta para deploy.
\n
• Cada tarefa — feature/nome.
\n
• Após a conclusão — Pull Request, code review, testes automatizados, merge em main.
\n
• Imediatamente após o merge — deploy (idealmente).
\n

Perfeito para projetos Kotlin com boa cobertura de testes.

2.3. Trunk-based — para os corajosos

Trabalha em uma startup ou fazendo um projeto pessoal? O Trunk-based (todos committam em main com commits curtos) acelera o desenvolvimento, mas requer