- O objetivo é criar a ferramenta de colaboração com git mais simples possível
- Tornar a execução de um servidor git auto-hospedado tão simples quanto executar um servidor SSH, sem sacrificar o tempo e a energia de colaboradores externos
- Combina listas de discussão e o fluxo de trabalho de pull request
- A ideia é criar uma ferramenta de colaboração tão simples quanto gerar patches, mas com a conveniência de uso de um pull request
- Em vez de criar mais um repositório de código, a proposta é construir uma solução git auto-hospedada extremamente simples para colaborar com contribuidores externos
O que é necessário
- O que o proprietário do código precisa para executar o servidor git:
- um único binário em golang
- O que um colaborador externo precisa:
- um par de chaves SSH
- um cliente SSH
Problemas atuais
- O e-mail é excelente como sistema distribuído para enviar e receber alterações em um repositório git (conjuntos de patches), mas fazer onboarding de novos usuários em uma mailing list, configurar corretamente um cliente de e-mail e então enviar uma contribuição de código já faz muitos desenvolvedores desistirem
- Como a colaboração aproveita o protocolo de e-mail, há limitações no conjunto de recursos. Por exemplo, não é possível editar e-mails, cada pessoa usa um cliente diferente, e esses clientes têm limitações distintas em relação a e-mails em texto puro e download de patches
- Os pull requests do Github são fáceis de usar, editar e gerenciar, mas têm a desvantagem de exigir que o usuário esteja dentro do site do Github para fazer code review
- Isso é bom para mudanças rápidas, mas quando você começa a ler código dentro do navegador, há desvantagens consideráveis. Em algum momento, faz mais sentido revisar o código no ambiente de desenvolvimento local ou em uma IDE
- Existem ferramentas e plugins para revisar PRs dentro da IDE, mas colocá-los para funcionar exige um esforço enorme
- Além disso, soluções auto-hospedadas que imitam pull requests exigem muita infraestrutura para serem gerenciadas. Banco de dados, site conectado ao git, administração, serviços etc.
- Outro grande ponto de atrito é que usuários externos geralmente precisam primeiro criar uma conta e fazer login antes de enviar alterações no código. Isso adiciona muito atrito tanto para contribuidores externos quanto para os donos do código, que precisam provisionar a infraestrutura
- Muitas vezes também é preciso fazer um fork do repositório antes de enviar um PR. Depois disso, a pessoa nunca mais contribui e mantém o fork para sempre. Isso parece bobo
Apresentando o Patch Request (PR)
- A ideia é criar um "servidor" git auto-hospedado que permita enviar e receber patches sem a inconveniência de configurar e-mail nem as limitações impostas pelo protocolo de e-mail
- Também querem que o fluxo de trabalho principal gire em torno do ambiente de desenvolvimento local. O Github vem tentando dar suporte a esse fluxo trazendo a IDE para o navegador, mas aqui a proposta é inverter essa ideia e tornar o code review dentro do ambiente local um recurso de primeira classe
- A proposta fica no meio do caminho entre o fluxo de pull request do Github e o envio/recebimento de patches por e-mail
- A ideia central é usar um app via SSH para lidar com a maior parte das interações entre contribuidores e donos do projeto. Tudo pode ser feito dentro do terminal, de forma ergonômica e com todos os recursos necessários
- As notificações são feitas via RSS, e toda mudança de estado leva à geração de ativos web estáticos, de modo que tudo pode ser hospedado usando um simples servidor de arquivos web
Fluxo de trabalho com format-patch
- Aqui, a ferramenta básica de colaboração é o
format-patch
- Tanto o envio de alterações quanto a revisão dessas alterações acontecem no próprio código
- Tanto contribuidores quanto proprietários criam novos commits e geram patches uns sobre os outros
- Isso elimina a necessidade de ter um visualizador web onde o revisor possa deixar um "comentário" em uma linha de um bloco de código. Não é necessário. Basta aplicar o patch do contribuidor, escrever comentários ou alterações no código, gerar um novo patch e enviar esse patch como "review" para o servidor git
- Esse fluxo funciona exatamente da mesma forma mesmo quando dois usuários colaboram em uma série de mudanças
- Isso também resolve o problema de enviar vários conjuntos de patches para a mesma alteração de código. Há um único Patch Request central onde todas as mudanças e colaborações acontecem
- Pode até ser possível encontrar uma forma de aproveitar
git note para revisões/comentários, mas, honestamente, essa solução parece brutal e fora da zona de conforto da maioria dos usuários de git
- Basta enviar a revisão como código e escrever comentários no código usando a linguagem de programação em uso
- Cabe ao contribuidor "processar" esses comentários e removê-los no patch seguinte
- Recurso obrigatório para tratar todos os comentários: se houver comentários não resolvidos no código, o patch não será mesclado. Eles não podem ser ignorados, caso contrário acabariam indo incorretamente para o upstream
Como o Patch Request funciona
- O Patch Request (PR) é a forma mais simples de enviar, revisar e aceitar mudanças em um repositório git. Ele funciona assim:
- o colaborador externo clona o repositório (
git-clone)
- o colaborador externo faz alterações no código (
git-add & git-commit)
- o colaborador externo gera um patch (
git-format-patch)
- o colaborador externo envia o PR para o servidor SSH
- o proprietário recebe uma notificação RSS sobre o novo PR
- o proprietário aplica o patch localmente a partir do servidor SSH (
git-am)
- o proprietário escreve sugestões no código (
git-add & git-commit)
- o proprietário envia a review canalizando o patch para o servidor SSH (
git-format-patch)
- o colaborador externo recebe uma notificação RSS sobre a review do PR
- o colaborador externo reaplica o patch (
git-am)
- o colaborador externo revisa e remove os comentários no código
- o colaborador externo envia outro patch (
git-format-patch)
- o proprietário aplica o patch localmente (
git-am)
- o proprietário marca o PR como aprovado e envia o código para
main (git-push)
1 comentários
Parece ser uma nova adição ao Pico.sh - uma coleção open source para gerenciar serviços web via SSH.
Anteriormente, ele já incluía itens como os seguintes.