O que é e como funciona na prática
controle de revisoes é o sistema que registra todas as alterações feitas num projecto ao longo do tempo. O mais usado no mundo é o Git. Ele guarda o histórico de cada ficheiro, permite voltar atrás, criar ramificações e juntar mudanças de várias pessoas. A ideia básica é simples: cada alteração gera um commit, que é uma foto do estado do projecto naquele momento. Na prática, o dia a dia parece isto. Você cria um ficheiro, adiciona ao repositório, faz um commit com uma mensagem. Trabalha mais um bocado, repete. Quando precisa de testar algo arriscado, cria uma branch nova. Se der problema, volta à branch principal e segue em frente. É isso. Nada de mágica.
A configuração inicial que poupa dores de cabeça
Muita gente pula esta parte e depois passa sufimento. Antes de começar qualquer coisa, configure o seu nome e email no Git. O comando é directo: git config --global user.name "seu nome" e git config --global user.email "seu@email.com". Isso aparece em cada commit que fizer. Se não configurar, o Git pega o nome do seu computador ou algo genérico que ninguém reconhece. Também configure o branch padrão. Nos repositórios novos, o Git costumava chamar o branch principal de "master". Agora em muitos lugares já é "main". Escolha um e seja consistente. Eu prefiro main. Muda o padrão com git config --global init.defaultBranch main. A partir daí, todo repositório novo que criar já nasce com o branch certo.
Como usar no dia a dia
Comece criando um repositório. Pode ser local mesmo, sem necessidade de servidor. Vá até a pasta do projecto e rode git init. Vai aparecer uma pasta .git que você nunca deve mexer manualmente. A partir dali, o Git começa a rastrear tudo. Para adicionar ficheiros, use git add. Pode adicionar ficheiro por ficheiro ou tudo de uma vez com git add . - mas cuidado com isto. O ponto adiciona absolutamente tudo, incluindo coisas que não devia. Eu já perdi algumas horas porque adicionei um ficheiro de log por engano e depois tive que desfazer. O mais seguro é usar git add com os nomes dos ficheiros que realmente quer versionar.
Depois de adicionar, faça o commit. git commit -m "mensagem descritiva". A mensagem importa mais do que muita gente imagina. "fix" ou "update" são mensagens ruins. Escreva algo que explique o que mudou e porquê. Algum tempo no futuro, quando você precisar entender porque uma mudança foi feita, vai agradecer a si mesmo por ter escrito uma mensagem decente. Verificar o estado do repositório é essencial. git status mostra o que está modificado, o que está em staging e o que não está sendo rastreado. git log mostra o histórico de commits. Use git log --oneline para uma versão mais resumida. git diff mostra as diferenças entre o que está no disco e o que está no último commit, ou entre dois commits. Essas três ferramentas resolvem 90% das situações.
Workflows comuns
O fluxo mais simples é o linear. Trabalha na branch principal, faz commits ali, termina. Funciona para projectos pequenos, de uma pessoa só. Quando o projecto cresce ou há mais gente, o modelo branching surge como necessidade. A estrutura mais usada é Gitflow, que tem branches de desenvolvimento, release e hotfix além da principal. Outro modelo popular é o GitHub Flow, bem mais simples: só main e branches temporárias para features. Eu uso basicamente GitHub Flow. Crio uma branch para cada feature ou correção, trabalho nela, faço os commits, quando está pronto faço um pull request e quem revir o código aprova ou pede mudanças. Depois faço merge e apago a branch. Sem complicação.
O problema que eu tive e a solução
Num projecto específico, eu tinha um ficheiro de configuração com credenciais de acesso a um serviço. Por descuido, adicionei esse ficheiro ao repositório e fiz commit. O ficheiro continha uma senha em texto plano. Só percebi depois de ter feito push para o repositório remoto. Nesse momento a coisa já tinha saído do controle local. A solução que usei foi remover o ficheiro do histórico inteiro, não apenas do repositório atual. Rodrei git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch secrets/config.env' --prune-empty HEAD. Isso reconstrói o histórico removendo o ficheiro de todos os commits. Depois forcei o push com git push origin main --force. Também adicionei o ficheiro ao .gitignore para garantir que nunca mais voltasse a acontecer.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Isto é importante: forçar push assim apaga o histórico de todos. Se outras pessoas já tiverem puxado o repositório, elas vão ter problemas. Sempre avise antes de fazer isso. E o mais óbvio: nunca coloque credenciais em repositórios. Use variáveis de ambiente ou ferramentas de gestão de segredos. É básico, mas acontece com frequência.
Erros comuns que novatos cometem
O primeiro erro é fazer commits enormes com tudo misturado. Feature nova, correção de bug, ajuste de formatação, tudo num único commit. Quando surge um problema, fica impossível saber o que mudou e quando mudou. Separe as coisas. Cada commit deve fazer uma única coisa coerente. O segundo erro é ignorar o .gitignore. Projetos Node têm node_modules, Python tem __pycache__, macOS cria .DS_Store. Se isso for parar no repositório, ele incha e o histórico fica poluído. Adicione padrões relevantes ao .gitignore antes de começar a versionar. Um .gitignore mal configurado é a causa número um de repositórios cheios de lixo.
O terceiro erro é acreditar que backup é sinónimo de versionamento. Ter uma cópia dos ficheiros noutra pasta não substitui o controlo de versões. Backup é para recuperação de desastre. Versionamento é para acompanhar mudanças, colaborar e voltar atrás de forma controlada. São coisas diferentes que complementam mas não substituem uma à outra.
Pontuações que ninguém conta
Git não é perfeito. Há situações onde ele se comporta de maneira contra-intuitiva. Por exemplo, quando dois colaboradores fazem push para o mesmo branch sem sincronizar, o Git rejeita o segundo push. A mensagem de erro pode ser confusa para quem não está habituado. A solução é fazer pull antes do push, ou configurar o repositório para aceitar apenas merges. Em repositórios compartilhados, restringir pushes diretos e obrigar pull requests evita que pessoas sobrescrevam trabalho alheio acidentalmente. Outro problema real é o histórico linear versus histórico ramificado. Commits de merge criam um grafo que pode ficar confuso visualmente. O comando git log --graph ajuda, mas ainda assim exige familiaridade. Uma alternativa é usar rebase para manter o histórico linear, mas rebase modify commits existentes e isso pode causar conflitos quando outras pessoas já têm cópias do histórico antigo. Use rebase com cuidado, preferencialmente só em branches locais que ninguém mais está usando.
Performance também é um factor que muitos ignoram. Repositórios grandes, especialmente com muitos binários ou ficheiros pesados, ficam lentos. O Git foi feito para código fonte, não para imagens ou vídeos. Se o projecto inclui esses tipos de ficheiro, considere o Git LFS (Large File Storage), que armazena ficheiros grandes num serviço separado e mantém apenas referências no repositório. Sem LFS, um repositório com gigabytes de assets pode tornar-se impraticável em poucos meses.
Alternativas ao Git
Se Git não se adequa ao seu caso, existem outras opções. Mercurial é similar mas com filosofia diferente: menos comandos, mais consistência. Bazaar é outro, embora menos activo hoje em dia. Para quem trabalha com binários grandes e pouco código, Subversion (SVN) ainda é usado em alguns contextos industriais. E para equipes que querem algo mais orientado a operações do que a código, ferramentas como Plastic SCM oferecem recursos visuais de versionamento que podem ser mais acessíveis. Git continua sendo o padrão da indústria. A maioria das plataformas - GitHub, GitLab, Bitbucket - é construída em torno dele. A curva de aprendizado existe, mas compensa. Depois de umas duas semanas de uso diário, a maior parte dos comandos entra no automático.
Dica rápida sobre repositórios remotos
Para conectar o seu repositório local a um remoto, use git remote add origin
