Descobrindo a extensão do git vendor .

Postagem cruzada do meu blog médio: https://medium.com/opsops/git-vendor-295db4bcec3a

Gostaria de apresentar a maneira correta de lidar com a venda de repositórios git.

O que é 'vendoring'?

A venda é uma maneira de integrar o trabalho de outras pessoas ao seu. É o oposto de 'vincular' a biblioteca de terceiros. Em vez de ter essa biblioteca como uma dependência, o aplicativo usa essa biblioteca como parte do próprio código-fonte e mantém esse código 'dentro' de si mesmo.

Normalmente, o fornecimento é feito por ferramentas de idiomas: empacotador, carga, pip, etc. Mas, às vezes, você precisa vender algo que não seja coberto por nenhum conjunto de ferramentas existente ou algo em vários idiomas, que é impossível encontrar a ferramenta de idioma 'essencial' para isso.

A solução para essa situação é vender no nível git. Você tem seu próprio repositório git (eu chamo de 'repositório de destino ') e deseja incorporar outro repositório (eu chamo de 'repositório de origem ') como um diretório no seu (repositório de destino).

O que você espera de um sistema de vendas bem projetado (independentemente do Git, seja ou não):

• Visibilidade Você quer saber que algum código é vendido, significa que não foi escrito pelo committer.
• Proveniência Você quer saber de onde vem. Qual foi o repositório que alguém integrou ao seu repositório há dois anos? E qual versão / commit é?
• Capacidade de atualização Você deseja atualizar esse código quando algum bug for corrigido no repositório original (ou tiver um novo recurso há muito esperado). Como caso especial da capacidade de atualização, você deseja excluir o código vendido (e somente ele).
• Repetibilidade A venda não deve ser a arte, deve ser o processo rígido à prova de erros. o fornecedor foo na barra deve produzir o mesmo resultado, independentemente de quem o tenha feito.
• Transportabilidade. Uma pessoa que está clonando seu repositório deve poder continuar lidando com o fornecedor exatamente da mesma maneira que você. Isso significa que todas as informações relacionadas ao fornecedor devem permanecer no git e devem ser transferidas durante o push / pull.
• Governança. Todas as alterações vendidas devem permanecer 'como estão' até que alguém as atualize. Além disso, você não deseja ter atualizações inesperadas (quebradas), deseja absolutamente manter as coisas vendidas disponíveis, mesmo que o repositório de origem não esteja mais disponível.
• Patchability. Você deseja ajustar o código vendido e ainda atualizá-lo para uma versão mais recente. De preferência, sem conflitos, mas pelo menos com visibilidade clara de onde esses conflitos haviam acontecido.

E, dando a natureza git do Git, você deseja que esse sistema seja compatível com ramificações. Se a ramificação A tiver vendido código na versão a1 e a ramificação B na versão b1, você deseja alternar entre eles toda vez que alternar entre A e B. Além disso, deseja alterar a versão a1 para a2 e a versão b1 para B2 sem se preocupar com versões em outro ramo.

... E você deseja poder vender mais de um repositório externo, para que o fornecedor não seja um evento único por repo.

Como você pode ver, é uma longa lista de requisitos. Analisei (outras) soluções existentes antes de chegar à melhor solução (git vendor).

Copiar e colar

Copiar e colar é uma maneira tão cruel de vender algo que não tenho nada de bom a dizer sobre isso. Você perde proveniência, visibilidade, atualizabilidade. Você não perde a transportabilidade, pois, em primeiro lugar, não há link para o repositório antigo. Não faça vendas assim.

Git-in-git

Este é um truque estúpido, mas um pouco funcional. Crie uma pasta vendored_foobar em seu repositório, entre em vendored_foobar e clone esse foobar. Volte ao nível superior e confirme todas as alterações que tiver.

Prós: simples de fazer, fornece proveniência local, governança e uma excelente patchablity.

Contras: É frágil, não sobrevive ao push (a pasta .git aninhada não é incluída no seu repositório, portanto, para observadores externos, o código comercial é indistinguível do seu próprio). Você perderá a transportabilidade e a proveniência a longo prazo.

Submodules

A idéia é que você tenha algumas pastas do seu git gerenciadas em outro git. É o mais antigo 'algo' que o git havia fornecido. Infelizmente, não é compatível com ramificações e não possui controle sobre o código vendido. Se o repositório remoto acabar, você não poderá usar seus submódulos.

E não esqueça o quão difícil é clonar este repositório.

subárvore git

O Git pode usar a maneira 'subárvore' de mesclar gits externos como pastas no repositório git local. É quase perfeito, exceto pela capacidade de atualização, repetibilidade, proveniência e visibilidade. Com exceção da escavação manual em um histórico do git, é impossível ver qual parte do repositório do git é vendida e qual não é. E você não tem ideia de onde essas mudanças estão vindo. Se o committer não escreveu isso, as informações são perdidas. E se ele tiver, não será repetível, pois pequenas alterações podem ocorrer durante o preenchimento dessa informação.

Então, insira o vencedor premiado, fornecedor git.

Fornecedor Git

O fornecedor Git é uma extensão incrível para o git, escrita por Brett Langdon há cerca de três anos. São apenas cerca de 200 linhas no bash, mas é tão bem escrito que não tenho nenhuma queixa sobre ele (ele tem tudo o que um bom programa deve ter: páginas de manual, ajuda, conclusão do bash, tratamento razoável de erros e proteções contra falhas).

Ele usa a subárvore git e estende-o com funções para cobrir os lados soltos do fornecedor pela subárvore git.

Cada ponto importante é verificado:

• visilibidade. Basta ligar para a git vendor list e ver todas as coisas vendidas.
• proveniência. Ele mostra o repositório remoto e permite ver qual confirmação foi vendida.
• atualizabilidade. git vendor update , e ele suporta ramificações, tags e confirmações como uma maneira de identificar exatamente o que levar. E você pode git vendor remove do git vendor remove , é claro.
• repetibilidade. Não há operações manuais envolvidas; portanto, todos obterão o mesmo resultado no fornecedor inicial ou após as atualizações.
• transportabilidade. Todas as alterações são armazenadas como tags especiais no histórico do git, portanto, são totalmente compatíveis com push / pull. E eles funcionam muito bem com filiais e checkouts de histórico arbitrários.
• govenrance. Todo o código vendido é armazenado dentro do seu repositório.
• rastreabilidade. É (você verá uma clara fusão de conflitos com suas alterações), mas é o lado mais fraco do fornecedor de git. Eu preferiria ter 'fila de patches' (como no debian / pathes para pacotes deb), mas, no entanto, existe um suporte mínimo para isso.

Ele possui uma política específica de como as coisas são vendidas: se você deseja clonar https://github.com/serverscom/dibctl ele entra em vendor/github.com/serverscom/dibctl/ . Você pode alterar a parte ' vendor/ ', mas o restante é uma política rígida. No entanto, os links simbólicos podem ser mais fáceis.

Existem alguns pequenos bugs: você não pode usá-lo em repositórios vazios, não pode usar gits locais como fontes, não pode ver ajuda até estar no repositório git. Nenhum deles causa problemas durante o trabalho normal com repositórios reais.

Conclusão

O git-vendor é uma ferramenta perfeita para vender um repositório git em outro. Ele fornece todas as funcionalidades necessárias para as melhores práticas de venda: manter a proveniência, fornecer visibilidade e capacidade de atualização.