Fazer commit — o que é, regras de formatação e trabalho com Git

O que é um commit no Git

Um commit no Git é um objeto que armazena o estado dos arquivos do projeto em um momento específico. Cada commit contém um snapshot de todos os arquivos rastreados, uma referência ao commit pai e metadados. Ao contrário de outros sistemas de controle de versão, o Git usa armazenamento endereçável por conteúdo — cada objeto é identificado por um hash SHA-1 do seu conteúdo.

Quando um desenvolvedor faz commit de alterações, o Git cria um objeto commit que armazena: um objeto tree (estrutura de arquivos), hash do commit pai, autor, committer, data e mensagem. Este objeto é imutável — uma vez criado, um commit não pode ser modificado sem alterar seu hash. Essa imutabilidade garante a integridade do histórico do projeto.

# Preparar alterações e fazer commit
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Ver detalhes do commit
git log --oneline -3
git show HEAD

# Preparar todas as alterações e fazer commit em uma etapa
git commit -a -m "Update dependencies to latest versions"

Os commits formam um grafo acíclico direcionado (DAG), onde cada novo commit referencia o anterior. Isso permite navegar pelo histórico, reverter alterações e analisar a evolução da base de código. Entender a estrutura do DAG do Git é a base para o trabalho avançado com commits.

Como fazer commit de alterações corretamente

O processo de commit no Git consiste em duas etapas: adicionar alterações à staging area (índice) e criar o commit. A staging area permite que o desenvolvedor selecione quais alterações específicas serão incluídas no commit, mesmo que muitos arquivos tenham sido modificados no diretório de trabalho.

A regra da atomicidade é o princípio-chave de um bom commit. Cada commit deve conter uma alteração lógica. Se um desenvolvedor corrige um bug e refatora código — são dois commits diferentes. Commits atômicos simplificam a revisão de código, a reversão de alterações e a análise do histórico.

Antes de fazer commit, vale a pena verificar: se restaram no código saídas de depuração, blocos comentados ou alterações acidentais. Para isso, usa-se o comando git diff --cached, que mostra exatamente o que será incluído no commit. Uma verificação adicional com git status exibe a lista de arquivos na staging area.

• Verifique as alterações — git diff --cached mostra o que será incluído no commit
• Verifique a qualidade — o código deve passar pelo linter e testes antes do commit
• Escreva uma mensagem — uma descrição clara do propósito da alteração
• Verifique os arquivos em staging — git status confirma a lista de arquivos

Regras para escrever mensagens de commit

A mensagem de commit é a documentação da alteração para futuros desenvolvedores. Uma boa mensagem responde às perguntas: o que foi alterado e por quê. A convenção Conventional Commits (equipe Angular, 2016) tornou-se um padrão para muitos projetos e define o formato: tipo(escopo): descrição.

Uma boa mensagem de commit consiste em um cabeçalho (até 50 caracteres) e um corpo (opcional, até 72 caracteres por linha). O cabeçalho é escrito no modo imperativo: “Add” não “Added” ou “Adds”. Capitalization e ponto final no cabeçalho não são usados — é uma convenção internacional do Git.

Uma mensagem ruim: “fix things” ou “update” — não traz informação. Em um mês, um desenvolvedor não conseguirá entender o que exatamente foi alterado e por quê. Uma boa mensagem: “fix(payment): handle timeout in stripe callback” — fica imediatamente claro o que e onde foi corrigido.

Erros comuns ao fazer commit

Desenvolvedores, especialmente iniciantes, frequentemente cometem erros típicos ao fazer commit. O mais comum é um commit muito grande, que mistura dezenas de alterações. Esse commit não pode ser revertido parcialmente, e a revisão de código se torna um tormento.

O segundo erro mais frequente é uma mensagem de commit ruim. Mensagens como “fix”, “update”, “changes” ou “wip” não fornecem contexto para futuros desenvolvedores. Em seis meses, ninguém lembrará o que exatamente foi corrigido. A regra é simples: imagine que daqui a um ano você está olhando o histórico tentando encontrar uma alteração específica.

O terceiro erro é fazer commit de código não compilado ou que não funciona. Após um commit, o código deve pelo menos compilar. Não quebrar a build é um requisito básico para qualquer commit em um branch compartilhado. Para isso, a build e os testes são executados antes do commit.

O quarto erro é fazer commit de dados confidenciais. Chaves de API, senhas e tokens não devem parar no histórico do Git. Se um segredo já foi commitado, não basta removê-lo em um novo commit — é preciso deletá-lo de todo o histórico através de git filter-branch ou BFG Repo-Cleaner.

Técnicas avançadas de trabalho com commits

O Git fornece ferramentas para gerenciar o histórico de commits. Uma das mais úteis é git commit --amend, que permite complementar o último commit com novas alterações ou corrigir a mensagem. É útil se o desenvolvedor esqueceu de incluir um arquivo ou cometeu um erro de digitação na mensagem.

# Corrigir a mensagem do último commit
git commit --amend -m "fix(auth): correct token validation logic"

# Adicionar arquivo esquecido ao último commit
git add missed-file.txt
git commit --amend --no-edit

# Rebase interativo para os últimos 3 commits
git rebase -i HEAD~3

O rebase interativo é uma ferramenta poderosa para reescrever o histórico. Permite combinar commits (squash), alterar mensagens (reword), reordenar (reorder) e excluir commits (drop). No entanto, o rebase modifica o histórico, por isso é usado apenas em commits locais que ainda não foram enviados para um repositório remoto.

Existem duas abordagens para reverter commits. git revert cria um novo commit que desfaz as alterações do anterior — um método seguro que preserva o histórico. git reset remove commits do histórico — perigoso se os commits já foram enviados. No desenvolvimento em equipe, apenas git revert é usado para desfazer commits publicados.