Eu tinha pavor de usar o Git. No meu primeiro emprego como desenvolvedor, eu suava frio toda vez que precisava enviar meu código para o repositório oficial da empresa. Eu jurava que ia quebrar o sistema inteiro se digitasse alguma coisa errada. Hoje, eu vou te mostrar exatamente os comandos essenciais que eu uso no dia a dia para que você perca o medo e assuma o controle do seu versionamento de código.
Se você sente que o Git é um monstro de sete cabeças e que a qualquer momento você vai perder todo o seu trabalho, esse vídeo é para você.
Passo #1: O básico que não pode faltar
O Git tem uma quantidade colossal de comandos e parâmetros obscuros, mas a verdade libertadora é que no dia a dia a gente acaba usando um subconjunto bem pequeno deles. É o famoso Princípio de Pareto: 20% dos comandos resolvem 80% dos seus problemas.
A espinha dorsal de qualquer rotina de desenvolvimento é bem simples. Você alterou um arquivo, salvou e agora quer que o Git acompanhe essa mudança. A sequência sagrada é:
git status: Seu melhor amigo. Ele te diz exatamente onde você está e quais arquivos foram modificados. Use toda hora.git add arquivo.php: É como colocar o arquivo numa caixa pronta para ser despachada.git commit -m "mensagem clara do que mudou": Aqui você fecha a caixa e coloca um rótulo. A dica de ouro: escreva mensagens que o seu "eu" do futuro vai entender.git push: Você pega essa caixa e envia para o servidor (como o GitHub ou GitLab).git pull: Você baixa as caixas que seus colegas de equipe enviaram para o servidor.
Se você dominar esse ciclo básico, já consegue trabalhar tranquilamente em quase qualquer projeto do mercado.
Passo #2: Branches — Isolando o caos
Imagina que você está construindo uma casa e quer testar uma pintura verde na parede da sala, mas tem medo de estragar a pintura original. Com o Git, você não precisa ter medo. Você cria uma "dimensão paralela", faz seus testes e, se ficar bom, você junta tudo na realidade principal. Essa dimensão paralela se chama Branch.
Trabalhar em uma branch separada evita que um código incompleto vá parar na main (a versão oficial do projeto) antes da hora. A rotina costuma ser:
git checkout -b minha-nova-feature: Cria a dimensão paralela e já te joga para dentro dela.- Você faz todo o seu trabalho, commita, testa...
git checkout main: Volta para a realidade principal.git merge minha-nova-feature: Puxa todas as novidades que você fez lá na dimensão paralela para a versão principal.
Isso dá uma segurança absurda. Se a sua feature der completamente errado, é só deletar a branch e seguir a vida como se nada tivesse acontecido.
Passo #3: Desfazendo coisas (com cuidado)
Todo mundo erra. Você alterou o arquivo errado, deletou algo que não devia ou fez um commit com o nome errado. O Git te permite voltar no tempo, mas você precisa saber qual botão apertar.
git restore arquivo.php: Fez uma bagunça no arquivo e quer que ele volte a ser o que era no último commit? Esse comando joga fora suas alterações não salvas.git reset --soft HEAD~1: Fez o commit mas esqueceu de adicionar um arquivo? Esse comando desfaz o último commit, mas deixa seus arquivos intactos para você commitar de novo do jeito certo.git revert <hash>: Se o erro já foi para o servidor (você já deu push), não tente apagar o histórico. O revert cria um novo commit que faz o exato oposto do commit com erro, desfazendo a ação sem bagunçar a vida da equipe.
Passo #4: O perigo mora ao lado
Você vai esbarrar em comandos que reescrevem o histórico do Git, como o reset --hard ou o famigerado git push --force. Esses comandos são poderosos, mas são exatamente eles que causam choro e ranger de dentes em projetos em equipe.
Eles literalmente apagam o passado. Se alguém da sua equipe já tinha baixado aquele código, o repositório deles vai entrar em conflito com o seu e a confusão estará armada. Eu uso esses comandos com extrema moderação, geralmente apenas nas minhas próprias branches isoladas e só quando tenho absoluta certeza do que estou fazendo.
Conclusão
No fim das contas, usar o Git de forma consciente não significa saber todos os comandos de cabeça. Significa entender o ciclo de vida do seu código e garantir que você e sua equipe consigam trabalhar de forma segura e organizada, sem medo de "quebrar" o projeto inteiro com um simples Enter.
