Git Commands Cheat Sheet: The 20 Commands You Actually Need — cod-ai.com

A Crise de Produção das 3 AM que Mudou a Forma como Eu Ensino Git

Eram 3:17 AM em uma terça-feira quando meu telefone explodiu com notificações. Nossa principal branch de produção estava quebrada, os deployments estavam falhando e ninguém conseguia descobrir o que havia dado errado. Eu era o engenheiro de DevOps sênior de plantão e, enquanto tropeçava até meu laptop, eu sabia exatamente o que tinha acontecido — alguém havia feito um force-push para a branch principal sem entender o que estava fazendo.

Aquele incidente nos custou aproximadamente $47,000 em receita perdida durante a interrupção de quatro horas. Mas, mais importante, me ensinou algo crucial: a maioria dos desenvolvedores não precisa realmente conhecer 200 comandos Git. Eles precisam dominar cerca de 20 comandos e compreendê-los bem o suficiente para evitar erros catastróficos.

Sou Marcus Chen, e eu trabalho como engenheiro de DevOps e líder técnico nos últimos 12 anos, principalmente em empresas de SaaS de médio a grande porte. Integrei mais de 150 desenvolvedores, revisei milhares de pull requests e resolvi mais desastres Git do que gostaria de lembrar. O que aprendi é que o domínio do Git não é sobre memorizar cada flag e opção — é sobre ter um modelo mental confiável e saber exatamente quais comandos usar em situações específicas.

Este cheat sheet representa a sabedoria destilada de mais de uma década de uso real do Git. Esses não são comandos teóricos que encontrei na documentação. Estes são os 20 comandos que uso quase diariamente, aqueles que ensino a cada novo membro da equipe e os que salvaram minha equipe de inúmeras horas de frustração. Cada comando aqui conquistou seu lugar por necessidade prática, não por completude acadêmica.

Antes de começarmos, deixe-me ser claro sobre algo: isso não é uma introdução para iniciantes ao Git. Se você é totalmente novo em controle de versão, você deve começar com o básico em outro lugar. Este guia é para desenvolvedores que já sabem que o Git existe e o usaram, mas querem aumentar sua eficiência e confiança. Você está cansado de procurar os mesmos comandos repetidamente. Você quer uma referência curada e testada em batalha que realmente reflete como os profissionais usam o Git em ambientes de produção.

A Base: Comandos que Você Usará Todos os Dias

Vamos começar com o absoluto essencial — os comandos que formam a espinha dorsal do seu fluxo de trabalho diário do Git. Eu uso esses comandos com tanta frequência que eles são praticamente memória muscular. Se você estiver trabalhando em uma equipe de qualquer tamanho, provavelmente usará cada um deles pelo menos uma vez por dia, muitas vezes várias vezes.

"O domínio do Git não é sobre memorizar cada flag e opção — é sobre ter um modelo mental confiável e saber exatamente quais comandos usar em situações específicas."

git status — Este é o seu comando de conscientização situacional. Eu executo isso provavelmente 30-40 vezes por dia, e não estou exagerando. Antes de cometer, após cometer, quando algo parece errado, quando você está mudando de contexto entre tarefas — git status te diz exatamente onde você está. Ele mostra quais arquivos estão preparados, quais foram modificados mas ainda não estão preparados, e quais são não rastreados. Pense nele como sua bússola Git. A saída é codificada por cores e notavelmente clara, razão pela qual é o primeiro comando que ensino a qualquer pessoa.

git add — Este prepara suas alterações para o commit. O uso mais comum é git add . para preparar tudo em seu diretório atual, mas eu realmente recomendo ser mais seletivo. Use git add nome-do-arquivo para preparar arquivos específicos, ou git add -p para preparação interativa onde você pode revisar e preparar pedaços individuais de alterações. Esse controle granular me salvou inúmeras vezes quando fiz várias alterações não relacionadas e precisei cometê-las separadamente. Na minha experiência, desenvolvedores que usam git add de forma descuidada criam históricos de commit bagunçados que tornam a depuração e a revisão de código significativamente mais difíceis.

git commit -m "mensagem" — Isso cria um instantâneo das suas alterações preparadas. A flag -m permite que você adicione uma mensagem de commit inline. Agora, aqui está onde compartilharei alguma sabedoria conquistada com muito esforço: suas mensagens de commit importam muito mais do que você pensa. Passei horas tentando entender por que uma alteração específica foi feita, apenas para encontrar uma mensagem de commit que diz "consertar coisas" ou "atualizações." Uma boa mensagem de commit deve completar esta frase: "Se aplicada, este commit irá..." Por exemplo: "Se aplicada, este commit irá adicionar autenticação de usuário ao ponto de acesso de login." Essa disciplina tornou a arqueologia de código infinitamente mais fácil para minhas equipes.

git push — Isso envia seus commits locais para o repositório remoto. Mais comumente, você usará git push origin nome-da-branch. A primeira vez que você envia uma nova branch, precisará usar git push -u origin nome-da-branch, onde a flag -u configura o rastreamento para que futuros pushes possam ser apenas git push. Não posso estressar isso o suficiente: nunca, jamais use git push --force em branches compartilhadas, a menos que você saiba exatamente o que está fazendo e tenha comunicado com sua equipe. Aquele incidente das 3 AM que mencionei? Foi um force push que deu errado.

git pull — Isso busca alterações do repositório remoto e as mescla na sua branch atual. Eu começo cada sessão de trabalho com um git pull para garantir que estou trabalhando com o código mais recente. Uma coisa crítica a entender: git pull é na verdade dois comandos combinados — git fetch seguido de git merge. Às vezes, você vai querer usar esses separadamente para mais controle, o que discutiremos mais tarde. Quando você puxa e há conflitos, o Git te dirá exatamente quais arquivos têm conflitos, e você precisará resolvê-los manualmente antes de continuar.

Branching: Seu Toolkit do Universo Paralelo

Branching é onde o verdadeiro poder do Git surge. É o que permite que vários desenvolvedores trabalhem em diferentes recursos simultaneamente sem pisar nos pés uns dos outros. Na minha equipe atual de 23 desenvolvedores, geralmente temos de 40 a 60 branches ativas a qualquer momento. Dominar esses comandos de branching é o que separa usuários casuais de Git de profissionais confiantes.

git branch — Executar