Pitch: Eu fiz uma camada em cima do Git para ter o poder do Git sem a parte em que ele tenta arruinar sua semana
Git é uma ferramenta incrível.
Também é uma ferramenta que, se você errar duas palavras em um comando, te dá a oportunidade de desenvolver caráter.
Foi dessa relação meio tóxica que nasceu o Anchor.
A ideia é simples de explicar: o Anchor funciona como uma camada em cima do Git. Em vez de tentar reinventar versionamento ou criar um “git alternativo”, ele pega tudo que já existe de poderoso no Git e coloca em volta uma interface mais inteligente, mais segura e mais útil no dia a dia.
Na prática, você pode usar o Anchor para praticamente tudo que já usaria no Git. A diferença é que agora existe uma ferramenta no meio do caminho tentando evitar que você descubra as consequências de um reset --hard da forma mais educativa possível.
O que eu queria resolver
Git é poderoso, mas ele não faz muita questão de te proteger de você mesmo.
Ele assume que você sabe exatamente o que está fazendo, exatamente em que branch está, exatamente o impacto do comando que digitou e exatamente o estado atual do repositório.
Na vida real, quase nunca é assim.
Na vida real, você está cansado, com 12 abas abertas, resolve “só arrumar uma coisinha rapidinho”, e 15 segundos depois está lendo reflog como se fosse um pergaminho antigo tentando entender onde sua paz interior foi parar.
O Anchor nasceu para atuar exatamente nesse ponto.
A proposta nunca foi substituir o Git.
A proposta foi criar uma camada que:
- mantém o poder do Git
- melhora a experiência de uso
- adiciona diagnóstico e análise de risco
- cria mecanismos de recuperação
- ajuda com commits melhores
- continua sendo totalmente open source
- não te obriga a depender de serviço pago ou plataforma fechada
A ideia central
Se o comando é algo que o Anchor entende nativamente, ele executa com toda a inteligência extra da ferramenta.
Se não for, ele repassa para o Git.
Ou seja: na prática, o Anchor funciona como um ponto de entrada único para o seu fluxo de versionamento.
Você continua usando os comandos que já conhece, mas ganha por cima uma camada que analisa o contexto do repositório, identifica risco, sugere ações mais seguras e, em alguns casos, cria pontos de recuperação antes da desgraça acontecer.
É quase como usar Git com cinto de segurança.
Ou, em casos mais graves, com airbag.
O que ele faz de interessante
Alguns exemplos do tipo de coisa que eu quis colocar no projeto:
anchor status
anchor log --oneline -5
anchor doctor
anchor commit-ai
anchor snapshot
anchor recover
anchor explain rebase main
A ideia é que você possa continuar usando o fluxo normal de terminal, mas com recursos que o Git puro não oferece de forma organizada.
O doctor, por exemplo, faz um check-up do repositório e tenta encontrar sinais de problema antes que você execute uma operação mais sensível.
Working tree suja, conflitos, merge pendente, rebase interrompido, detached HEAD, divergência com upstream, arquivos suspeitos não rastreados e outros estados que normalmente só viram “problema real” quando já é tarde demais.
É basicamente um exame preventivo para o seu repositório.
O tipo de coisa que parece exagero até o dia em que salva sua pele.
A parte técnica que me divertiu de verdade
O que eu mais gostei no Anchor é que ele começou com uma ideia simples e rapidamente virou um projeto de engenharia bem mais interessante do que parecia.
Porque “fazer um wrapper de Git” é fácil.
O difícil é fazer isso direito.
No Anchor, eu quis separar o sistema em camadas bem definidas, com responsabilidades claras. Em vez de virar só um monte de comando jogado em um CLI, o projeto foi organizado em módulos como domínio, aplicação, integração com Git, IA, diagnóstico, recuperação, localização e apresentação.
Isso muda bastante a qualidade do código.
A ferramenta deixa de ser só um experimento de terminal e começa a virar uma base real para evoluir.
A integração com Git em si é direta e consciente: o Anchor executa o Git como processo, captura saída, erro e código de retorno, e trabalha em cima disso. Nada de abstrações mágicas tentando esconder o que está acontecendo. No final, continua sendo Git. A diferença é que agora existe um sistema em volta dele observando, interpretando e ajudando.
Esse detalhe era importante para mim: eu não queria uma ferramenta “mística”. Eu queria uma ferramenta honesta.
Análise de risco antes da besteira
Uma das partes mais legais do projeto foi modelar risco como algo explícito.
Alguns comandos não são só “comandos”. Eles são decisões com potencial destrutivo.
reset --hard, clean, rebase, switch com alterações locais, merges em estado sensível… tudo isso pode ser executado normalmente no Git, mas cada um tem um impacto real no estado do repositório.
Então o Anchor tenta entender esse contexto antes da execução.
Em vez de simplesmente repassar o comando e torcer pelo melhor, ele analisa o estado do repo, interpreta o tipo de operação, calcula risco, identifica possíveis perdas e pode até preparar mecanismos de recuperação antes de continuar.
Eu gosto muito dessa ideia porque ela muda a relação com a ferramenta.
O Git puro normalmente responde depois.
O Anchor tenta conversar antes.
Snapshot e recovery
Se a ferramenta vai falar de segurança, ela precisa oferecer mais do que conselho.
Por isso uma das partes importantes do projeto é o sistema de snapshot e recovery.
Antes de operações arriscadas, o Anchor pode criar pontos de recuperação para preservar o estado atual. A ideia é simples: se algo der errado, você tem um caminho razoável para voltar ao estado anterior sem depender exclusivamente de memória, sorte e rituais com reflog.
Isso não transforma Git em videogame com botão de undo infinito, claro.
Mas cria uma camada prática de proteção em cima de um fluxo que normalmente é bastante impiedoso com erro humano.
E, honestamente, “menos chance de entrar em pânico no terminal” já é uma feature excelente.
IA, mas do jeito que eu acho certo
Outra parte que eu quis fazer direito foi a integração com IA.
Hoje muita ferramenta enfia IA em qualquer lugar e chama isso de inovação. Normalmente significa mandar contexto para uma API, esperar uma resposta meio aleatória e fingir que isso é arquitetura.
Eu queria evitar exatamente isso.
No Anchor, a IA entra como uma camada opcional e desacoplada, principalmente para coisas como geração de commit message. O projeto foi pensado para trabalhar com providers diferentes, com suporte a execução local por padrão, especialmente via Ollama, e com fallback determinístico quando a IA não está disponível ou falha.
Esse ponto, para mim, é um dos mais importantes do projeto.
IA não pode ser o ponto único de falha da sua ferramenta.
Se a IA estiver fora do ar, o Anchor continua útil.
Se o modelo responder mal, o Anchor continua útil.
Se você não quiser depender de serviço externo, o Anchor continua útil.
Esse é o tipo de decisão que parece pequena em demo, mas faz toda a diferença em ferramenta real.
Open source de verdade
Uma coisa que eu queria muito no Anchor era evitar a sensação de “isso aqui é legal, agora faça login, conecte sua conta, aceite nossos termos e talvez pague uma mensalidade para continuar”.
Não.
A proposta do projeto é ser uma ferramenta 100% open source, que você possa rodar, entender, modificar, usar localmente e integrar ao seu fluxo sem precisar pedir permissão para ninguém.
Isso vale especialmente para a parte de IA local por padrão, mas vale também para a filosofia geral do projeto.
Eu queria uma ferramenta para developers, feita do jeito que developers gostam de usar ferramenta.
Sem enfeite desnecessário.
Sem caixa preta obrigatória.
Sem te prender num ecossistema.
O que eu acho mais interessante no Anchor
Pra mim, o ponto mais legal do projeto é que ele não tenta competir com o Git.
Ele assume que o Git já é absurdamente poderoso.
O problema nunca foi falta de poder.
O problema sempre foi falta de contexto, falta de guard rail e falta de uma camada mais humana entre o comando digitado e o estrago potencial.
O Anchor tenta ser essa camada.
Não para te impedir de usar Git de verdade.
Mas para te deixar usar Git com mais confiança, mais previsibilidade e menos chance de transformar uma tarefa simples em um evento canônico.
No fim, era isso
Eu gosto muito de projeto que parece simples quando você resume em uma frase, mas fica bem mais interessante quando abre o código.
“Uma camada em cima do Git” parece pouca coisa.
Até você perceber que isso envolve roteamento de comandos, leitura de estado do repositório, análise de risco, diagnóstico, snapshots, recovery, abstração de IA, fallback determinístico, localização e uma arquitetura suficientemente modular para o projeto crescer sem virar um cemitério de if no CLI.
O Anchor ainda está no começo, mas a base dele já está muito mais próxima de uma ferramenta séria do que de um experimento aleatório de fim de semana.
E sinceramente, essa era exatamente a ideia.
Se alguém quiser testar, olhar o código, sugerir melhorias ou contribuir, o projeto está aqui: