5 hábitos de Git que fazem um desenvolvedor parecer júnior (e como corrigir cada um)

Introdução

Git não é só uma ferramenta de versionamento — é um registro público de como você trabalha. Antes mesmo de olhar o código, quem revisa um pull request já forma uma opinião sobre o nível técnico do autor só pelo histórico de commits.

Isso não é sobre decorar comandos. É sobre disciplina: pequenos hábitos que, repetidos centenas de vezes ao longo de um projeto, definem se o histórico do repositório ajuda ou atrapalha quem vai mantê-lo depois — inclusive você mesmo, seis meses no futuro.

Este artigo cobre os 5 hábitos mais comuns que sinalizam falta de maturidade no uso de Git, o motivo técnico de cada um ser problemático e a alternativa que desenvolvedores experientes usam no lugar.

Hábito 1 — Commit gigante com mensagem vaga

O padrão mais comum: alterar dez arquivos, mexer em três funcionalidades diferentes, e resumir tudo isso em uma linha genérica.

git commit -m "ajustes"

Por que é um problema: essa mensagem não diz nada sobre o que mudou, por quê, ou o que esperar se algo quebrar. Quando alguém (ou você) precisar rodar git log ou git bisect para encontrar em qual commit um bug foi introduzido, um histórico cheio de “ajustes” e “correções” transforma uma busca de 5 minutos em uma investigação de horas.

O que fazer no lugar: commits atômicos — cada commit representa uma única mudança lógica — com mensagem no imperativo, descrevendo o quê e, se necessário, o porquê.

git commit -m "fix: corrige cálculo de frete para CEPs internacionais"
git commit -m "feat: adiciona login com Google"

Um padrão amplamente adotado para isso é o Conventional Commits, que define prefixos como fix:, feat:, refactor:, docs: para categorizar a natureza da mudança.

Hábito 2 — git add . sem revisar o que está sendo enviado

Adicionar tudo que está na área de trabalho, sem checar o conteúdo, é rápido — e arriscado.

git add .
# sobe .env, node_modules, arquivos de configuração local, tudo junto

Por que é um problema: é assim que credenciais, chaves de API e arquivos de ambiente acabam vazando em repositórios públicos. Mesmo com um .gitignore bem configurado, arquivos novos que ainda não foram ignorados corretamente passam despercebidos.

O que fazer no lugar: usar git add -p (modo patch), que mostra cada trecho de mudança individualmente e pergunta se ele deve ou não entrar no commit.

git add -p
# revisa pedaço por pedaço antes de decidir

Isso força uma revisão manual do diff antes do commit — um hábito que também ajuda a identificar código de debug esquecido (console.log, print) antes que ele vá para produção.

Hábito 3 — Trabalhar direto na branch main

Sem isolar o trabalho em uma branch própria, qualquer commit — testado ou não — já está na branch que representa o estado “oficial” do projeto.

Por que é um problema: a main deixa de ser confiável como ponto de partida estável. Se alguém precisar fazer deploy de emergência ou criar uma nova branch a partir dela, corre o risco de herdar código quebrado ou incompleto.

O que fazer no lugar: uma branch por feature ou correção, criada a partir da main e mesclada de volta só quando pronta.

git switch -c feat/login

Esse isolamento é a base de fluxos como Git Flow e Trunk-Based Development — a diferença entre eles está em quão long-lived as branches são, mas o princípio de nunca commitar direto na branch principal é comum a praticamente todos os fluxos de trabalho profissionais.

Hábito 4 — git pull que termina em merge bagunçado

Rodar git pull sem parâmetros, quando existem commits locais não sincronizados, cria automaticamente um merge commit.

git pull
# cria um commit "Merge branch 'main' of ..." sem nenhum valor informativo

Por que é um problema: esse merge commit não representa nenhuma mudança de código — só documenta que duas pessoas trabalharam ao mesmo tempo. Repetido dezenas de vezes, ele polui o histórico e dificulta a leitura linear do que realmente aconteceu no projeto.

O que fazer no lugar: git pull --rebase, que reaplica os commits locais por cima do que foi baixado, mantendo o histórico linear.

git pull --rebase
# histórico limpo, sem merge commit desnecessário

Vale o alerta: rebase reescreve o histórico. É seguro para commits que ainda não foram compartilhados publicamente; para branches já compartilhadas com outras pessoas, é preciso mais cuidado (ver hábito 5).

Hábito 5 — Force push na branch compartilhada

Este é o mais arriscado da lista, porque o dano não é só estético — é destrutivo.

git push --force
# sobrescreve o histórico remoto, apagando qualquer commit que outra pessoa tenha enviado

Por que é um problema: se um colega deu push depois do seu último fetch, o --force apaga o trabalho dele sem aviso nenhum. Não há confirmação, não há como desfazer facilmente — o commit simplesmente deixa de existir na branch remota.

O que fazer no lugar: git push --force-with-lease, que verifica se a branch remota está exatamente como você a viu por último antes de sobrescrever.

git push --force-with-lease
# só sobrescreve se ninguém enviou commits novos desde o seu último fetch

Se alguém tiver enviado algo entre o seu fetch e o push, o comando falha em vez de apagar silenciosamente o trabalho alheio — o que te dá a chance de revisar antes de decidir o próximo passo.

Checklist resumo

Perguntas frequentes

Rebase é sempre mais seguro que merge? Não. Rebase reescreve o histórico de commits, o que é seguro em branches locais ou pessoais, mas pode causar conflitos e confusão em branches já compartilhadas com outras pessoas. A regra prática: nunca faça rebase de uma branch que outra pessoa já baixou e está usando.

--force-with-lease elimina totalmente o risco do force push? Reduz drasticamente o risco de sobrescrever trabalho alheio sem aviso, mas não substitui comunicação com o time. Em branches críticas (como main ou develop), a maioria das equipes simplesmente bloqueia force push via regras de proteção de branch no GitHub/GitLab.

Preciso seguir o Conventional Commits à risca? Não é obrigatório, mas adotar um padrão de prefixos consistente (mesmo que simplificado) facilita a geração automática de changelogs e a leitura do histórico por qualquer pessoa do time, não só por quem escreveu o commit.

Conclusão

Nenhum desses cinco hábitos exige aprender um comando novo e complexo — todos usam ferramentas que já existem no Git. A diferença entre um histórico confuso e um histórico útil não está em conhecimento técnico, está em disciplina: revisar antes de commitar, isolar o trabalho em branches, e tratar o histórico como documentação viva do projeto, não como um detalhe descartável.

Corrigir esses pontos não muda o que o código faz — muda quanto tempo a próxima pessoa (ou você mesmo) vai gastar entendendo por que ele faz o que faz.

Meta descrição: Conheça 5 hábitos de Git que denunciam falta de experiência e aprenda as alternativas usadas por desenvolvedores sêniores: commits atômicos, git add -p, branches por feature, rebase e force-with-lease.

Slug sugerido: 5-habitos-git-desenvolvedor-junior

Tags: Git, GitHub, Boas Práticas de Programação, Controle de Versão, Desenvolvimento de Software, Git Rebase