Git e GitHub Básico: Controle de Versão para Quem Coda

Trabalhar sem controle de versão é como editar um documento importante sem a função desfazer: um erro pode custar horas de trabalho. Git, criado por Linus Torvalds em 2005, é o sistema de controle de versão distribuído padrão da indústria. GitHub, a maior plataforma de hospedagem de repositórios, transforma Git em uma ferramenta de colaboração em equipe. Dominar ambos é requisito básico para qualquer desenvolvedor em 2026.

O Que é Git e Por Que Usar

Git registra alterações em arquivos ao longo do tempo, permitindo recuperar versões específicas, comparar mudanças e colaborar sem sobrescrever o trabalho dos outros. Cada desenvolvedor possui uma cópia completa do repositório, incluindo todo o histórico. Isso elimina dependência de um servidor central e permite trabalho offline.

Controle de versão não é apenas para código. Designers usam Git para arquivos Figma exportados, escritores para rascunhos, cientistas de dados para notebooks e datasets versionados. Qualquer projeto que evolui ao longo do tempo se beneficia de versionamento.

Instalação e Configuração Inicial

Git está disponível para Windows, macOS e Linux. Após instalar, configure identidade e editor preferido. Essas informações são embutidas em cada commit que você cria.

# Instalação (exemplos)
# macOS: brew install git
# Ubuntu/Debian: sudo apt install git
# Windows: winget install Git.Git

# Configuração global
git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"
git config --global init.defaultBranch main

# Verificar configurações
git config --list

# Inicializar repositório
git init

# Clonar repositório existente
git clone https://github.com/usuario/repositorio.git

Ciclo Básico de Trabalho

O fluxo diário de Git envolve quatro estágios: working directory (arquivos modificados), staging area (arquivos marcados para commit), commit (fotografia do estado atual), e remote (sincronização com servidor). Compreender esses estágios evita commits acidentais e arquivos esquecidos.

# Verificar status do repositório
git status

# Adicionar arquivo ao staging
git add arquivo.txt

# Adicionar todos os arquivos modificados
git add .

# Criar commit com mensagem descritiva
git commit -m "feat: adiciona validação de email no formulário"

# Ver histórico de commits
git log --oneline --graph --decorate

# Desfazer staging (manter modificações)
git reset HEAD arquivo.txt

# Desfazer modificação não commitada (cuidado!)
git checkout -- arquivo.txt

Branches e Estratégias de Ramificação

Branches permitem desenvolver funcionalidades isoladas sem afetar o código principal. O modelo Git Flow propõe branches permanentes (main, develop) e temporárias (feature, release, hotfix). Para projetos menores, o trunk-based development com feature branches curtas é mais ágil e reduz conflitos.

# Criar e mudar para nova branch
git checkout -b feature/login-social

# Equivalente moderno (Git 2.23+)
git switch -c feature/login-social

# Listar branches
git branch -a

# Mudar entre branches
git switch main

# Mesclar branch na atual
git merge feature/login-social

# Deletar branch local após merge
git branch -d feature/login-social

# Deletar branch remota
git push origin --delete feature/login-social

Commits Semânticos e Mensagens de Qualidade

Mensagens de commit bem escritas são documentação viva do projeto. A convenção Conventional Commits usa prefixos como feat, fix, docs, style, refactor, test e chore. Isso permite geração automática de changelogs e versionamento semântico (semver).

Uma boa mensagem explica o que mudou e por que, não apenas como. Compare "fix bug" com "fix: corrige race condition em cache durante concorrência alta". A segunda permite que futuros mantenedores entendam o contexto sem ler o diff.

Resolução de Conflitos

Conflitos ocorrem quando duas branches modificam a mesma parte de um arquivo. Git marca as regiões conflitantes com <<<<<<<, ======= e >>>>>>>. A resolução é manual: edite o arquivo, remova os marcadores, adicione ao staging e finalize o commit.

# Durante merge ou rebase, Git sinaliza conflitos
# Edite os arquivos marcados, remova os delimitadores

# Após resolver manualmente
git add .
git commit -m "merge: resolve conflitos na integração OAuth"

# Visualizar conflitos de forma gráfica
git mergetool

# Abortar merge em andamento
git merge --abort

# Abortar rebase em andamento
git rebase --abort

Pull Requests e Revisão de Código

Pull Request (PR) é o mecanismo central de revisão de código no GitHub. Antes de mesclar uma branch, a equipe revisa diffs, discute implementações e executa pipelines de CI. PRs bem escritos aceleram revisão e reduzem bugs em produção.

• Descreva o que o PR faz, por que é necessário e como testar.
• Mantenha PRs pequenos e focados — idealmente menos de 400 linhas modificadas.
• Inclua screenshots para mudanças visuais (UI/UX).
• Responda a comentários construtivamente, sem levar para o pessoal.
• Use checklists de revisão: testes passam? Documentação atualizada? Breaking changes documentadas?

GitHub Actions e CI/CD Básico

GitHub Actions automatiza testes, lint e deploy a cada push ou pull request. Workflows são definidos em arquivos YAML dentro do repositório. Um pipeline mínimo executa testes e verifica formatação antes de permitir merge.

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
      - run: npm ci
      - run: npm run lint
      - run: npm run test
      - run: npm run build

Fluxos de Trabalho Profissionais

Equipes estabelecem regras para manter histórico limpo e previsível. Rebase antes de merge elimina commits de merge desnecessários. Squash condensa múltiplos commits de feature em um único commit coeso. Tags anotadas marcam releases pontuais.

# Rebase interativo para limpar histórico
git rebase -i HEAD~5

# Squash: combine commits ou edite mensagens
# No editor, mude 'pick' para 'squash' ou 'reword'

# Criar tag anotada para release
git tag -a v1.2.0 -m "Release v1.2.0 — adiciona relatórios PDF"
git push origin v1.2.0

# Stash: salvar modificações temporariamente
git stash push -m "WIP: refatorando serviço de email"
git stash list
git stash pop

# Buscar alterações de outra branch sem merge
git cherry-pick abc1234

Erros Comuns e Como Evitar

• Commitar arquivos sensíveis (.env, chaves privadas). Use .gitignore e git-secrets para prevenção.
• Fazer commits gigantes que misturam múltiplas funcionalidades. Commits atômicos são mais fáceis de revisar e reverter.
• Trabalhar diretamente na main sem branch de feature. Isso bloqueia a equipe e dificulta code review.
• Usar git push --force sem entender as implicações. Prefira --force-with-lease, que aborta se houver novos commits.
• Deixar mensagens de commit vagas como 'update' ou 'fix'. Seja específico sobre o que e por que.
• Esquecer de fazer pull antes de push, criando branches divergentes desnecessariamente.

Conclusão

Git e GitHub são habilidades fundamentais que transcendem linguagens de programação. Um desenvolvedor que domina branches, commits semânticos, resolução de conflitos e pull requests colabora de forma mais eficiente e produz código de maior qualidade. O investimento em aprender bem essas ferramentas retorna em produtividade medida em horas economizadas por semana.

Comece praticando em um repositório pessoal. Crie branches, experimente rebase, abra pull requests consigo mesmo. A fluência vem da repetição diária. Quando Git se tornar automático, você poderá focar no que realmente importa: resolver problemas e construir software de qualidade.

Perguntas frequentes

Fontes consultadas

• Pro Git — Livro Oficial (Gratuito)
• GitHub Docs — GitHub Actions
• Conventional Commits
• Oh Shit, Git!?! — Resolução de Problemas
• GitHub Learning Lab