Ask HN: Podemos fazer melhor do que Git para controle de versão?

Discussão no Hacker News ↗

A dominância do Git como sistema de controle de versão é amplamente reconhecida, mas muitos engenheiros argumentam que ele está longe de ser ideal, especialmente em termos de usabilidade, lidar com ativos binários grandes e suportar monorepos enormes. Comentadores apontam alternativas como Fossil, Mercurial, Perforce, Pijij e Jujutsu, além de camadas de UI e ferramentas construídas sobre o Git, como evidência de que fluxos de trabalho e modelos melhores são possíveis. A visão predominante é que os efeitos de rede e o ecossistema do GitHub tornam improvável uma substituição total no curto prazo, então a maior parte da inovação prática está focada em interfaces melhores, merges mais inteligentes e sistemas especializados para ativos não relacionados a código, em vez de abandonar o Git por completo.

Sentimento geral sobre o Git

  • Muitos consideram o Git “bom o suficiente” e provavelmente dominante por muito tempo por causa de sua ubiquidade e ecossistema, e não porque seja ideal.
  • Outros argumentam que está longe de ser um problema resolvido: UI confusa, padrões ruins e algumas limitações arquitetônicas reais.
  • Vários comentários observam que o Git substituiu sistemas piores (RCS/CVS/SVN) e resolveu problemas importantes, mas agora ele próprio parece datado.

UX, modelo mental e curva de aprendizado

  • Reclamações repetidas sobre conceitos e comandos confusos: commit vs push vs pull vs fetch, área de staging, rebase, reflog, etc.
  • Alguns querem um “modo fácil” mais simples, com um pequeno conjunto de comandos seguros (“salvar / atualizar”) e um “modo expert” para operações avançadas.
  • Há tensão entre “ferramentas para profissionais, complexidade é aceitável” e “má UX desperdiça tempo e não se justifica”.
  • GUIs e ferramentas de nível mais alto (IDEs, apps desktop, frontends TUI, wrappers como Graphite, Magit, etc.) são vistas como formas eficazes de domar o Git.

Pontos de dor técnicos e arquiteturais

  • Arquivos grandes e assets binários: Git LFS é visto como desajeitado e frágil; fluxos de trabalho de desenvolvimento de jogos e CAD muitas vezes preferem Perforce ou SVN.
  • Monorepos muito grandes: problemas de desempenho com varreduras de status, tamanho do histórico e muitos arquivos; as alternativas incluem sistemas de arquivos virtuais, clones esparsos/parciais e ferramentas específicas de fornecedores.
  • Resolução de conflitos: os algoritmos atuais de merge são considerados “rápidos, mas burros”; modelagem limitada de conflitos (sem “estado em conflito” como conceito de primeira classe), renomes difíceis e falta de entendimento semântico.
  • Modelo de armazenamento: snapshot de blobs vs. baseado em patches; alguns argumentam que sistemas baseados em patches (Darcs, Pijul) permitem melhores merges e melhor raciocínio sobre o histórico.

Alternativas e novos sistemas

  • Frequentemente mencionados: Fossil (tickets/wiki integrados, histórico imutável), Mercurial e derivados (Sapling, sistemas internos do Google), Darcs, Pijul, Jujutsu, Perforce e ferramentas específicas de domínio (por exemplo, Oxen para grandes conjuntos de dados de IA).
  • Algumas ferramentas novas permanecem compatíveis com Git no nível de armazenamento/protocolo, mas oferecem novas UIs ou semânticas, sendo vistas como mais fáceis de adotar do que uma ruptura completa.

Hospedagem, centralização e efeitos de rede

  • A dominância do Git está fortemente ligada ao GitHub e a forges similares; a descoberta e as contribuições sofrem fora do GitHub.
  • Alternativas como GitLab, Forgejo/Gitea, SourceHut, Codeberg e hospedagem Fossil existem, mas enfrentam os efeitos de rede.
  • A federação entre forges é mencionada como uma possível forma de reduzir o lock-in.

Direções futuras

  • Ideias levantadas: diffs/merges semânticos, armazenamento de código baseado em AST, histórico de branches como objeto de primeira classe, melhor rastreamento de histórico físico, rastreamento de movimentos integrado ao editor e fluxos de trabalho mais centrados em centralização.
  • Não está claro se alguma delas ganhará impulso suficiente para deslocar o Git; adicionar melhorias em camadas sobre o Git é visto como o caminho mais realista no curto prazo.