Git e GitHub para Iniciantes: Guia Prático do Zero

Se você está começando a programar, cedo ou tarde vai ouvir falar de Git e GitHub. Eles são tão presentes no mercado que praticamente toda vaga de desenvolvimento pede esse conhecimento. A boa notícia é que, para o uso do dia a dia, você precisa dominar poucos conceitos e alguns comandos. Neste guia, vou explicar tudo de forma prática, do que é controle de versão até como colaborar em projetos com outras pessoas.

O que é controle de versão?

Imagine que você está escrevendo um trabalho e salva vários arquivos: "trabalho_final.docx", "trabalho_final_v2.docx", "trabalho_final_agora_vai.docx". Controle de versão resolve exatamente esse problema, só que de forma organizada. Ele registra cada alteração feita nos arquivos do projeto, quem fez, quando fez e por quê. Assim, você pode voltar para qualquer versão anterior, comparar mudanças e trabalhar em equipe sem que uma pessoa sobrescreva o trabalho da outra.

Git e GitHub não são a mesma coisa

Essa é uma confusão muito comum entre iniciantes:

• Git é a ferramenta de controle de versão. Ele roda no seu computador e funciona até sem internet. Foi criado em 2005 por Linus Torvalds, o mesmo criador do Linux.
• GitHub é uma plataforma online que hospeda repositórios Git. Ele adiciona recursos de colaboração, como pull requests, issues, revisão de código e automações. Alternativas populares são o GitLab e o Bitbucket.

Em resumo: o Git é o motor, e o GitHub é um lugar na nuvem onde você guarda e compartilha os seus projetos.

Instalando e configurando o Git

Baixe o Git no site oficial (git-scm.com) ou instale pelo gerenciador de pacotes do seu sistema. Depois, configure seu nome e e-mail, que vão aparecer em todos os seus commits:

git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

Use o mesmo e-mail da sua conta do GitHub, assim seus commits ficam associados ao seu perfil.

Os três estados de um arquivo

Entender esse conceito evita muita confusão. No Git, seus arquivos passam por três áreas:

• Working directory (diretório de trabalho): onde você edita os arquivos normalmente.
• Staging area (área de preparação): onde você coloca as alterações que quer incluir no próximo commit.
• Repositório: onde os commits ficam salvos permanentemente no histórico.

Essa separação permite que você escolha exatamente o que vai em cada commit, mesmo que tenha mexido em vários arquivos.

Comandos essenciais do dia a dia

Com estes comandos, você resolve a grande maioria das situações:

git init                 # cria um repositório na pasta atual
git status               # mostra o que mudou
git add arquivo.html     # adiciona um arquivo à staging area
git add .                # adiciona todas as alterações
git commit -m "mensagem" # salva as alterações no histórico
git log --oneline        # mostra o histórico de commits
git diff                 # mostra as diferenças ainda não adicionadas

O git status é o seu melhor amigo. Sempre que estiver em dúvida sobre o que está acontecendo, rode ele.

Escrevendo boas mensagens de commit

Uma mensagem de commit deve explicar o que foi feito e, se não for óbvio, por quê. Compare:

• Ruim: "ajustes", "update", "corrigindo coisas".
• Bom: "Corrige validação de e-mail no formulário de contato", "Adiciona página de política de privacidade".

Uma prática comum é escrever no imperativo e manter a primeira linha curta, com até uns 50 caracteres. Muitas equipes também usam o padrão Conventional Commits, com prefixos como feat:, fix: e docs:.

Branches: trabalhando em paralelo

Branches (ramificações) permitem desenvolver uma funcionalidade nova sem mexer na versão estável do projeto. A branch principal normalmente se chama main. Para criar uma nova e trocar para ela:

git switch -c nova-funcionalidade   # cria e muda para a branch
git switch main                     # volta para a main
git merge nova-funcionalidade       # traz as mudanças para a main

A ideia é simples: cada funcionalidade ou correção ganha sua própria branch. Quando estiver pronta e testada, ela é mesclada (merge) na principal.

Conectando com o GitHub

Depois de criar um repositório vazio no GitHub, conecte o seu projeto local a ele e envie os commits:

git remote add origin https://github.com/seu-usuario/seu-projeto.git
git push -u origin main

A partir daí, os comandos principais para sincronizar são:

• git push: envia seus commits locais para o GitHub.
• git pull: baixa e integra as alterações que estão no GitHub.
• git clone URL: copia um repositório existente para o seu computador.

Pull requests e revisão de código

Em equipes, ninguém costuma enviar código direto para a main. O fluxo mais comum é: criar uma branch, fazer os commits, enviar para o GitHub e abrir um pull request (PR). O PR é um pedido para mesclar suas mudanças, e é ali que os colegas revisam o código, comentam e sugerem melhorias antes da aprovação.

Esse processo melhora a qualidade do código, espalha conhecimento pelo time e evita que erros cheguem à produção.

Lidando com conflitos

Conflitos acontecem quando duas pessoas alteram a mesma linha de um arquivo. O Git não sabe qual versão manter e pede sua ajuda. Ele marca o trecho com <<<<<<<, ======= e >>>>>>>. Você edita o arquivo, decide o resultado final, remove as marcações e faz um novo commit. Parece assustador no início, mas com o tempo vira rotina. Editores como o VS Code ajudam muito, mostrando botões para aceitar uma versão ou outra.

O arquivo .gitignore

Nem tudo deve ir para o repositório. Pastas como node_modules, arquivos de build e, principalmente, arquivos com senhas e chaves de API (como o .env) devem ficar de fora. Para isso, crie um arquivo .gitignore na raiz do projeto listando o que deve ser ignorado:

node_modules/
.env
dist/

Nunca envie senhas para o GitHub, mesmo em repositórios privados. Se isso acontecer por engano, troque a senha imediatamente, porque o histórico do Git guarda tudo.

GitHub como portfólio

Além de ferramenta de trabalho, o GitHub é uma vitrine. Recrutadores costumam olhar o perfil de candidatos para ver projetos, frequência de contribuições e qualidade do código. Mantenha um README bem escrito em cada projeto, explicando o que ele faz, como rodar e quais tecnologias foram usadas. Fixe no perfil os repositórios que melhor representam o seu trabalho.

Conclusão

Git parece complicado no começo, mas o uso diário se resume a poucos comandos: status, add, commit, push e pull, junto com o conceito de branches. Comece usando Git em todos os seus projetos pessoais, mesmo os pequenos. Em pouco tempo, ele vira parte natural do seu fluxo, e você vai se perguntar como trabalhava sem ele.