GitRoot

 (gitroot.dev)
2 pontos por GN⁺ 1 일 전 | 1 comentários | Compartilhar no WhatsApp
  • GitRoot é uma pequena forge Git que gerencia repositórios e permissões de acesso em um único binário, combinando issues, quadros, mesclagem de branches e interface web por meio de plugins independentes
  • Além do código, todos os dados, incluindo issues, merge requests e quadros, são armazenados no Git como arquivos comuns, sem depender de banco de dados separado ou blobs ocultos
  • As mudanças são controladas com .gitroot/users.yml e permissões de escrita por branch, e só usuários autorizados podem fazer push para a branch padrão, que representa o estado atual do repositório
  • Atualmente está em versão alfa e oferece suporte a repositórios, usuários, plugins, comandos Git via SSH e consulta HTTP, mas não é adequado para uso em produção
  • Até a versão 1.0, o projeto pretende implementar atualizações, permissões por arquivo, comandos Git via HTTP, grupos e subgrupos, além de estabilizar a API de plugins; hoje, para contribuir, é preciso entender Git e o fluxo do plugin grafter

Uma pequena forge Git com apenas os recursos necessários

  • GitRoot é uma pequena forge Git executada em um único binário, limitando as funções básicas à criação de repositórios e ao gerenciamento de permissões de acesso por repositório
  • Os demais recursos ficam a cargo de plugins que podem ser instalados de forma independente entre si
    • criação de issues, roadmaps, sprints e milestones
    • exibição de itens em formato de quadro
    • revisão e mesclagem de branches, chamadas de graft no GitRoot
    • fornecimento de dados do repositório e vários recursos por meio de uma interface web
  • Como os plugins são totalmente separados, é possível usar apenas o quadro sem interface web, e também criar plugins próprios com os recursos necessários para cada projeto

Um design para adaptar a forge a cada projeto

  • Partindo da ideia de que cada projeto precisa de um modo de trabalho diferente, o sistema foi projetado para que cada projeto tenha a liberdade de modificar sua própria forge
  • O ambiente desejado pelo desenvolvedor é o seguinte
    • armazenar código, issues, pull/merge requests e quadros em um único repositório
    • oferecer recursos necessários para divulgação e operação do projeto, como landing page, traduções, sistema de tickets e fórum
    • migrar para outra forge em outro servidor sem scripts de migração nem perda de dados ou de atribuição de contribuidores
  • Em contrapartida, busca evitar as seguintes complexidades
    • a necessidade de abrir o navegador para gerenciar pull/merge requests ou issues
    • uma configuração que mostra primeiro uma lista de arquivos e diretórios para quem está conhecendo o projeto
    • uma forge que define o significado e o fluxo de trabalho de sprints, milestones, épicos e user stories
    • uma estrutura em que é preciso passar por vários menus para configurar uma única permissão de usuário

Autonomia na instalação e operação

  • O objetivo é uma distribuição sem dependências nem banco de dados, para que administradores possam instalar e manter com facilidade
  • O administrador deve poder definir as ações permitidas para cada usuário, e os próprios usuários devem poder solicitar diretamente a criação e o acesso a projetos e recursos, sem depender de e-mail ou chat
  • A meta é reduzir o peso das atualizações, ao mesmo tempo em que se evita entregar dados de projetos e usuários a terceiros ou depender de grandes empresas que podem mudar suas políticas de operação de repente
  • O projeto ainda não está concluído e está recebendo contribuições externas

Permissões gerenciadas com arquivos comuns e branches

  • Em vez de usar banco de dados ou blobs ocultos dentro da árvore Git, todos os dados são armazenados em arquivos comuns ao lado do código
  • O .gitroot/users.yml de cada repositório define onde cada usuário pode escrever, e o controle de acesso funciona principalmente com restrições por branch
    • no início, apenas o proprietário pode acessar a branch padrão
    • se um usuário sem permissão fizer push para a branch padrão, o GitRoot rejeita a mudança
    • qualquer pessoa pode criar uma nova branch, e quem a criou recebe permissão de escrita nessa branch; outros usuários não podem modificá-la
    • se .gitroot/users.yml for alterado, ou se for mesclada uma branch em que um usuário adicionou a si mesmo, esse usuário também poderá fazer push para a branch padrão
  • Qualquer pessoa pode ler os arquivos e modificá-los localmente ou em uma nova branch, mas para refletir mudanças na branch padrão, que representa o estado atual do repositório, é necessária a mesclagem feita pelo proprietário
  • As configurações da própria forge também são gerenciadas no repositório raiz
    • um repositório é criado ao adicionar uma mudança em .gitroot/repositories.yml da branch padrão do repositório raiz, ou ao mesclar essa mudança
    • mais detalhes sobre o funcionamento estão na documentação

Recursos disponíveis na versão alfa

  • Como esta é atualmente uma versão alfa, é possível testar, mas ela não deve ser usada em produção
  • O suporte atual inclui
    • criação e exclusão de repositórios
    • processamento de comandos Git via SSH
    • gerenciamento de locais de escrita por usuário no nível de repositório e branch
    • instalação de plugins e ativação por repositório
    • execução de plugins na árvore de trabalho durante a instalação
    • execução de plugins sobre o diff a cada commit após a instalação
    • consulta de repositórios via HTTP

Plano de desenvolvimento até a 1.0

  • Antes da versão 1.0, o projeto pretende implementar os seguintes recursos
    • atualização do GitRoot e dos plugins
    • gerenciamento de permissões de usuário no nível de arquivo
    • processamento de comandos Git via HTTP
    • gerenciamento de repositórios com grupos e subgrupos
    • estabilização da API de plugins

Self-hosting e processo de contribuição

  • O site do GitRoot é uma instância do GitRoot que hospeda o próprio código do GitRoot, operando exclusivamente para o projeto GitRoot
  • Para testar em outro projeto, é preciso seguir a documentação de instalação e uso
  • Como o próprio GitRoot também é um repositório GitRoot, é possível contribuir da mesma forma, e o processo pode ser consultado no guia de contribuição
  • A instância atual usa o plugin grafter para integrar parte do código à branch padrão, então é preciso entender como ele funciona antes de contribuir
  • Como todos os dados, incluindo código, issues e traduções, são armazenados no Git, hoje é necessário saber usar Git para contribuir
  • No futuro, o objetivo é permitir que qualquer pessoa participe executando git commit e git push diretamente no navegador

Leituras relacionadas

1 comentários

 
GN⁺ 1 일 전
Opiniões no Lobste.rs
  • O GitHub não era apenas o maior repositório Git, mas também o mais influente, e essa marca é perceptível até no design do Forgejo e do GitLab. O declínio do GitHub pode abrir espaço para o surgimento de vários repositórios que fujam do modelo existente, aumentando a margem para inovação
    • O Gitea praticamente copiou o frontend do GitHub numa relação 1:1 no passado, e o Forgejo herdou essa forma ao fazer fork do Gitea
  • Sou a pessoa que criou o GitRoot, então fiquem à vontade para perguntar qualquer coisa
    • Tenho curiosidade sobre três pontos. Gostaria de entender por que o CSS foi commitado em estado minificado: https://gitroot.dev/worktree/app/…
      A causa de a largura da tag <pre> ficar limitada a 720px parece ser o display:grid do body; se isso for desativado, ela se expande como esperado. Além disso, como a URL não contém informações de um commit específico, fica difícil para quem enviou e quem recebeu o link verem a mesma tela. Entendo que é um projeto para necessidade pessoal, mas quis trazer isso como algo que vale revisar
  • @manland, queria saber se existe alguma política ou orientação sobre permitir ou proibir contribuições feitas com LLM
    • No momento não há uma política separada. Isso porque, tirando dois contribuidores ocasionais, 99,999% do código foi escrito por mim
      Pessoalmente não uso LLM para programar e sou contra, mas mesmo que alguém usasse, se o patch fosse pequeno o bastante, não tenho certeza se recusaria
      Como o inglês não é minha língua nativa e por isso tenho dificuldade para explicar o GitRoot, há traços de LLM na comunicação externa. Antes também pedi ajuda em https://gts.gitroot.dev/@forge/statuses/01KFNWDKSZBEHTC16N5G02HJZ6 e https://gts.gitroot.dev/@forge/statuses/01KTP30NTY9FK91Q9B5Z9B4M52, mas ninguém apareceu
      Dói ter de usar LLM, mas em vez de não fazer nada, decidi usar o mínimo possível. Se surgir uma comunidade no futuro, gostaria de excluir isso completamente, e antes disso talvez desapareça naturalmente por motivos econômicos. Tenho muitos textos pendentes na lista de tarefas para explicar filosofia, segurança e o futuro, mas acabo hesitando em escrevê-los ao pensar que no fim a LLM vai ajustar as frases, corrigir erros de digitação e traduzir
  • Gostei do uso de TinyGo para compilar plugins em Go para WASM