13 Comandos Git Essenciais para Desenvolvedores em 2025

Dominar Git vai além de decorar comandos: é entender quando cada um resolve um problema real. Esta lista reúne os 13 comandos que aparecem com mais frequência no dia a dia de um desenvolvedor, do primeiro commit à correção de um erro no histórico. Se você está começando ou quer revisar a base, este guia entrega o essencial, sem rodeios.

O ciclo básico de trabalho com Git começa com git init ou git clone, passa por git status, git add e git commit, e depois se ramifica em operações de branch, merge, log e correção. Cada comando abaixo tem um critério objetivo de uso, para você não ficar perdido entre as dezenas de opções disponíveis.

1. git init

O git init cria um novo repositório Git em um diretório existente. É o ponto de partida para qualquer projeto que ainda não usa controle de versão.

Quando usar: no início de um projeto local, quando você quer transformar uma pasta comum em um repositório. Após executar, o Git passa a rastrear as alterações dos arquivos naquele diretório.

Exemplo: git init cria a pasta .git com toda a estrutura interna do repositório. A partir daí, você pode fazer o primeiro git add e git commit.

2. git clone

O git clone copia um repositório remoto para a sua máquina. É a forma mais comum de começar a trabalhar em um projeto que já existe no GitHub, GitLab ou outro servidor.

Quando usar: sempre que você precisa de uma cópia local de um repositório remoto, seja para contribuir ou apenas para testar o código.

Exemplo: git clone https://github.com/usuario/repositorio.git baixa todo o histórico de commits, branches e tags do projeto para uma pasta local.

3. git status

O git status mostra o estado atual do repositório: quais arquivos foram modificados, quais estão na área de staging e quais ainda não foram rastreados. É o primeiro comando que você deve executar ao abrir o terminal em um projeto Git.

Quando usar: antes de qualquer operação, para saber exatamente o que mudou desde o último commit. Ele evita surpresas, como commitar um arquivo indesejado.

Exemplo: após editar um arquivo, git status exibe a mensagem "modified: arquivo.txt" em vermelho, indicando que a alteração ainda não foi adicionada ao commit.

4. git add

O git add adiciona arquivos à área de staging, preparando-os para o próximo commit. É o passo intermediário entre a edição do código e o registro da alteração.

Quando usar: quando você quer incluir uma alteração específica no próximo commit. Você pode adicionar um arquivo único (git add arquivo.txt) ou todos os arquivos modificados (git add .).

Exemplo: git add . adiciona todos os arquivos modificados e novos ao staging. Depois, git commit registra essas mudanças no histórico.

5. git commit

O git commit salva o estado atual da área de staging em um ponto fixo do histórico. Cada commit deve ter uma mensagem clara, descrevendo o que foi alterado e por quê.

Quando usar: a cada unidade lógica de trabalho, como corrigir um bug ou adicionar uma funcionalidade. Commits pequenos e frequentes facilitam o rastreamento de problemas.

Exemplo: git commit -m "Corrige bug no cálculo de juros" registra a alteração com uma mensagem objetiva. A mensagem deve ser no imperativo e resumir a mudança em até 50 caracteres.

6. git branch

O git branch lista, cria ou exclui branches. Branches são linhas independentes de desenvolvimento, úteis para trabalhar em features sem afetar a branch principal.

Quando usar: para isolar uma nova funcionalidade ou experimento. No fluxo padrão, você cria uma branch por feature, trabalha nela e depois faz o merge de volta para a branch principal.

Exemplo: git branch feature-login cria um novo branch chamado "feature-login". Para listar todos os branches, use git branch sem argumentos.

7. git checkout

O git checkout alterna entre branches ou restaura arquivos para um estado anterior. É o comando que você usa para mudar de contexto no projeto.

Quando usar: para trocar para uma branch existente (git checkout feature-login) ou para criar uma nova já trocando (git checkout -b nova-branch). Também serve para descartar alterações não commitadas em um arquivo.

Exemplo: git checkout -b hotfix-urgente cria e já ativa a branch "hotfix-urgente", economizando um passo.

8. git merge

O git merge integra as alterações de uma branch em outra. É a forma mais comum de unir o trabalho feito em branches paralelas.

Quando usar: quando você concluiu uma feature e quer incorporá-la à branch principal, ou quando quer atualizar uma branch com as novidades de outra.

Exemplo: estando na branch main, git merge feature-login traz as alterações da branch "feature-login" para a branch atual. Conflitos podem ocorrer e precisam ser resolvidos manualmente.

9. git rebase

O git rebase reaplica os commits de uma branch sobre outra, criando um histórico linear. É uma alternativa ao merge, usada para manter a história limpa.

Quando usar: em projetos que preferem um histórico linear, ou para atualizar uma branch de feature com as últimas mudanças da main antes de um merge. Use com cautela em branches compartilhadas, pois reescreve o histórico.

Exemplo: git rebase main na branch "feature-login" reaplica os commits da feature sobre o estado atual da main, deixando o histórico sem bifurcações.

10. git log

O git log exibe o histórico de commits do repositório. É a ferramenta para entender o que foi feito, por quem e quando.

Quando usar: para revisar o histórico antes de um merge, para encontrar um commit específico que introduziu um bug, ou simplesmente para acompanhar a evolução do projeto.

Exemplo: git log --oneline mostra uma lista compacta de commits, com hash curto e mensagem, facilitando a navegação visual.

11. git stash

O git stash guarda temporariamente as alterações não commitadas, deixando o diretório de trabalho limpo. É útil quando você precisa mudar de contexto rapidamente sem perder o trabalho em andamento.

Quando usar: quando você está no meio de uma alteração e precisa trocar para outra branch ou resolver um bug urgente. O stash permite guardar as mudanças e recuperá-las depois.

Exemplo: git stash limpa o diretório de trabalho. Para recuperar as alterações, use git stash pop, que aplica as mudanças e remove o stash.

12. git revert

O git revert desfaz um commit específico, criando um novo commit que inverte as alterações. É a forma segura de corrigir um erro sem reescrever o histórico.

Quando usar: quando você precisa desfazer uma alteração que já foi enviada para um repositório remoto e outros desenvolvedores podem ter baseado seus trabalhos nela.

Exemplo: git revert HEAD desfaz o último commit, criando um novo commit que reverte as alterações. O histórico original permanece intacto.

13. git reset

O git reset move o ponteiro da branch para um commit anterior, descartando ou mantendo as alterações conforme o modo usado. É um comando poderoso e perigoso, que deve ser usado com cuidado.

Quando usar: para desfazer commits locais ainda não enviados ao remoto, ou para limpar a área de staging. Use git reset --hard apenas quando tiver certeza de que não precisa das alterações descartadas.

Exemplo: git reset --soft HEAD~1 desfaz o último commit, mantendo as alterações na área de staging. Já git reset --hard HEAD~1 descarta o commit e as alterações, voltando ao estado anterior.

Como escolher o comando certo para cada situação

A escolha entre merge e rebase depende do estilo do time. Se o projeto valoriza um histórico linear e você trabalha em uma branch local, o rebase mantém a história limpa. Em branches compartilhadas, o merge é mais seguro, pois não reescreve o histórico. Para desfazer erros, prefira revert em repositórios remotos e reset apenas em commits locais. O stash é o aliado para mudanças de contexto rápidas, e o log é o seu mapa para entender o passado do projeto.

FAQ

O que é a área de staging no Git?

A área de staging é um espaço intermediário entre o diretório de trabalho e o repositório. Quando você usa git add, as alterações vão para essa área. O git commit então registra essas alterações no histórico. Ela permite que você selecione quais mudanças entram em cada commit.

Qual a diferença entre git merge e git rebase?

O merge cria um novo commit de integração, preservando o histórico original com bifurcações. O rebase reescreve o histórico, aplicando os commits de uma branch sobre outra de forma linear. O merge é mais seguro para branches compartilhadas; o rebase mantém o histórico mais limpo, mas altera os hashes dos commits.

Como desfazer o último commit sem perder as alterações?

Use git reset --soft HEAD~1. Esse comando move o ponteiro da branch para o commit anterior, mas mantém as alterações na área de staging. Você pode então fazer novos ajustes e commitar novamente. Se quiser descartar as alterações, use git reset --hard HEAD~1, mas com cautela.

O que fazer quando um git merge dá conflito?

O Git marca os arquivos com conflito e interrompe o merge. Você precisa editar cada arquivo, escolhendo entre as versões ou mesclando manualmente. Depois, use git add para marcar como resolvido e git commit para concluir o merge. Ferramentas visuais como VS Code ajudam a resolver conflitos.

Como recuperar alterações guardadas com git stash?

Use git stash pop para aplicar as alterações mais recentes do stash e removê-las da lista. Se quiser manter o stash, use git stash apply. Para listar todos os stashes, git stash list; para ver o conteúdo de um stash específico, git stash show -p stash@{0}.

Preciso decorar todos os comandos Git?

Não. O essencial é entender o ciclo status, add, commit, push e pull. Os demais comandos, como rebase e reset, são usados em situações específicas. Com a prática, eles se tornam naturais. Consulte a documentação oficial sempre que tiver dúvida.