Fluxo de trabalho Git para desenvolvedor Java: como não enlouquecer em pull requests

Fluxo de trabalho Git para desenvolvedores Java: quando "apenas commitar" já não funciona

Sejamos honestos: todo desenvolvedor Java já passou pela situação em que, após um merge mal-sucedido, seu projeto parou de compilar e os colegas no chat escreveram "Quem mexeu no pom.xml?". Se você se identificou, este artigo é para você.

Git não é apenas um sistema de controle de versão. No mundo Java, onde os projetos duram anos e as dependências são gerenciadas via Maven ou Gradle, um fluxo de trabalho Git correto se torna uma questão de sobrevivência. Hoje vamos analisar como organizar o trabalho com Git para que o code review seja rápido e os conflitos não se tornem uma dor de cabeça.

Não vamos ensinar comandos como git init ou git commit. Em vez disso, vamos nos concentrar em como exatamente as equipes Java constroem seus processos: desde a escolha do modelo de ramificação até a configuração de pipelines de CI/CD.

Por que projetos Java exigem uma abordagem especial para Git?

Java é uma linguagem com um ecossistema rico. Em um projeto enterprise típico, você encontrará:

• Arquitetura em camadas (controller → service → repository);
• Build com Maven ou Gradle com dezenas de dependências;
• Testes longos (integração, unitários, E2E);
• Requisitos rigorosos de compatibilidade de versões.

Isso significa que o fluxo de trabalho Git para desenvolvedores Java deve levar em conta não apenas o código, mas também a infraestrutura de build. Um erro no pom.xml pode quebrar todo o projeto, e um conflito no application.properties pode parar o deploy.

Principais modelos de ramificação: o que escolher para sua equipe Java

GitFlow — o clássico do Java enterprise

GitFlow é o padrão de facto para grandes projetos Java. Ele oferece uma estrutura rigorosa de branches:

• main — apenas código pronto para produção;
• develop — branch de integração para desenvolvimento;
• feature/ — para novas funcionalidades;
• release/ — para preparação de release;
• hotfix/ — para correções urgentes.

Exemplo: você está escrevendo um novo endpoint REST no Spring Boot. Você cria a branch feature/add-user-endpoint a partir de develop, trabalha nela e depois faz o merge de volta. Quando houver funcionalidades suficientes para um release, cria-se release/v2.1.0, onde os bugs são corrigidos sem adicionar novas funcionalidades.

Vantagens: isolamento claro, histórico compreensível, adequado para versionamento.
Desvantagens: complexidade, muitos merges, inconveniente para CI/CD.

GitHub Flow — para iterações rápidas

Se sua equipe Java usa microsserviços ou trabalha com Agile, o GitHub Flow pode ser mais simples. Aqui há apenas uma branch principal — main. Todas as alterações passam por pull requests.

Funciona assim:

1. Crie uma branch a partir de main;
2. Escreva o código e os testes;
3. Abra um PR, passe pelo code review;
4. O CI/CD executa o build e os testes;
5. Após o merge, a branch é excluída.

Para um projeto Java, isso significa que cada PR deve ser pequeno o suficiente para que o CI consiga executar todos os testes em um tempo razoável.

Trunk-based development — para os corajosos

É quando todos os desenvolvedores trabalham em uma única branch (trunk) e as funcionalidades são ocultadas por feature flags. Adequado para equipes maduras com excelente cobertura de testes. Em Java, é frequentemente usado com Spring Cloud Config para ativar/desativar funcionalidades dinamicamente.

Merge vs Rebase: a eterna discussão dos desenvolvedores Java

No mundo Java, merge e rebase têm filosofias diferentes. Vamos analisar com um exemplo.

Merge — preservando o histórico

Se você está trabalhando em um módulo grande com vários desenvolvedores, o merge cria um commit de merge que mostra visualmente de onde vieram as alterações. Isso é útil para entender