Git subrepo

O projeto git-subrepo existe há muito tempo, no entanto, existem poucas referências a ele. O autor de git-subrepo é Ingy döt Net .

Se você examinar o histórico dos commits da ramificação principal do projeto, pode parecer que o projeto foi interrompido há 2 anos. No entanto, o trabalho no projeto está em andamento e espero que a versão 0.4.0 seja lançada em breve.

Uma propriedade importante dessa ferramenta é que não é necessário que o usuário instale o git-subrepo até que o usuário decida fazer confirmações no repositório upstream de subprojetos. Além disso, o usuário recebe uma árvore de origem totalmente preparada e configurada no momento da cópia do repositório principal, usando o comando git-clone (1) padrão.

Ao escolher meios de oferecer suporte a sub-módulos / subárvores / subprojetos do repositório principal de contêiner, o desenvolvedor primeiro determina o intervalo de recursos que esse ou aquele mecanismo fornece e responde às seguintes perguntas:

• se é necessário manter o histórico completo do subprojeto no repositório principal ou confirmações compactadas o suficiente;
• se a capacidade de fornecer alterações do subprojeto para o repositório upstream da subárvore é necessária;
• Existe a necessidade de conectar tags fixas do repositório upstream do subprojeto ou é possível conectar ramificações;
• se será necessário remover ainda mais os próprios subprojetos e, o que se tornou desnecessário, parte da história desses subprojetos;
• se o usuário precisará executar alguma ação para configurar manualmente os subprojetos após a clonagem do repositório do projeto principal;
• quão trabalhosa será a questão de analisar o histórico de conexão de subprojetos e revisões específicas das quais o subprojeto se origina;
• como essa ou aquela ferramenta afetará a política de gerenciamento de configuração de origem e quanto essa ferramenta complicará o trabalho diário dos engenheiros.

Obviamente, esta lista de perguntas não pode refletir a plenitude dos parâmetros de entrada necessários para a escolha certa, mas para uma revisão preliminar das ferramentas existentes, é suficiente e, falando do projeto git-subrepo , instamos o leitor a considerar esse projeto a partir dessas posições.

Instalação Git-subrepo

O pacote git-subrepo , no lado do desenvolvedor, pode ser instalado localmente, em seu diretório inicial e no nível do sistema.

No primeiro caso, basta clonar o repositório git-subrepo no diretório desejado, por exemplo, ~ / bin :

bash-4.4$ cd ~/bin bash-4.4$ git clone https://github.com/ingydotnet/git-subrepo.git 

e configure variáveis ​​de ambiente

 bash-4.4$ vim subrepo-env.sh #!/bin/sh export GIT_SUBREPO_ROOT="/home/username/bin/git-subrepo" export PATH="/home/username/bin/git-subrepo/lib:$PATH" export MANPATH="/home/username/bin/git-subrepo/man:$MANPATH" :wq bash-4.4$ source ./subrepo-env.sh 

Se você observar as variáveis ​​definidas no Makefile git-subrepo :

 # Install variables: PREFIX ?= /usr/local INSTALL_LIB ?= $(DESTDIR)$(shell git --exec-path) INSTALL_EXT ?= $(INSTALL_LIB)/$(NAME).d INSTALL_MAN1 ?= $(DESTDIR)$(PREFIX)/share/man/man1 

é fácil descobrir que, no nível do sistema, o git-subrepo está instalado no diretório em que o Git está localizado:

 bash-4.4$ bash-4.4$ git --exec-path /usr/libexec/git-core bash-4.4$ 

Portanto, o comando para instalar o git-subrepo pode parecer, por exemplo, o seguinte:

 bash-4.4$ make PREFIX=/usr install 

A presença da variável DESTDIR nos permite criar um pacote para qualquer distribuição Linux sem esforços adicionais (é claro, se não estivermos em um ambiente cruzado), o que pode ser útil para os engenheiros do DevOps.

Instale o git-subrepo como root:

 bash-4.4$ bash-4.4$ cd git-subrepo/ bash-4.4$ make PREFIX=/usr install install -C -d -m 0755 /usr/libexec/git-core/ install -C -m 0755 lib/git-subrepo /usr/libexec/git-core/ install -C -d -m 0755 /usr/libexec/git-core/git-subrepo.d/ install -C -m 0755 lib/git-subrepo.d/help-functions.bash lib/git-subrepo.d/bash+.bash /usr/libexec/git-core/git-subrepo.d/ install -C -d -m 0755 /usr/share/man/man1/ install -C -m 0644 man/man1/git-subrepo.1 /usr/share/man/man1/ bash-4.4$ 

Para analisar os recursos do git-subrepo, precisamos de um ambiente de teste simples, onde possamos reproduzir cenários operacionais padrão.

Ambiente de teste

Criamos três diretórios proprietário , remoto , usuário , nos quais colocamos modelos de repositórios upstream e locais do desenvolvedor e do usuário.

 bash-4.4$ vim _init.sh #!/bin/sh CWD=`pwd` mkdir remote owner user cd remote git init --bare build-system.git git init --bare platform.git cd ../owner git clone $CWD/remote/build-system.git git clone $CWD/remote/platform.git cd build-system echo -e "\n[master] build-system 1.0.0\n" >README git add README git commit -m "init build-system master 1.0.0" git push cd ../platform echo -e "\n[master] platform 1.0.0\n" >README git add README git commit -m "init platform master 1.0.0" git push cd ../../user git clone $CWD/remote/build-system.git git clone $CWD/remote/platform.git cd $CWD :wq bash-4.4$ bash-4.4$ ./_init.sh bash-4.4$ 

Aqui

O autor do projeto e os usuários têm suas próprias cópias dos repositórios upstream em suas máquinas, apresentadas em nosso exemplo nos diretórios proprietário e usuário , respectivamente.

A tarefa do autor é incluir os seguintes recursos na árvore principal da plataforma, incluindo o subprojeto do sistema builld na árvore principal:

• clone o repositório principal com o subprojeto do sistema de compilação incluído em sua estrutura e não se preocupe em configurar versões ou revisões. Ou seja, cada ramificação do repositório da plataforma deve corresponder a uma revisão específica de uma ramificação específica do repositório do sistema de construção e o usuário deve receber uma árvore de origem customizada em uma operação git-clone (1) , sem nenhuma ação adicional.
• entregar suas alterações no repositório de projetos upstream, tanto no principal quanto no auxiliar.
• receber alterações feitas por outros participantes ou usuários do projeto, é claro, se eles tiverem os direitos apropriados.

Considere as ações do autor que ele deve implementar para implementar esses requisitos.

Conexão de subprojeto

Para conectar uma nova subárvore, use o comando git subrepo clone , que, em sua finalidade, é semelhante ao comando git-clone (1) . O parâmetro necessário para o comando é a URL do repositório remoto. Você também pode especificar o diretório em que o subprojeto e a ramificação do repositório remoto estarão localizados. Trabalharemos com ramificações principais, portanto, em nosso exemplo, omitimos parâmetros de comando desnecessários.

Portanto, o autor do projeto, em sua máquina de trabalho, pode conectar o subprojeto do sistema de compilação usando o clone git subrepo clone ../../remote/build-system.git/ comando build-system :

 bash-4.4$ bash-4.4$ cd owner/platform/ bash-4.4$ git subrepo clone ../../remote/build-system.git/ build-system Subrepo '../../remote/build-system.git' (master) cloned into 'build-system'. bash-4.4$ 

Considere quais mudanças ocorreram no repositório da plataforma local:

 bash-4.4$ bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ bash-4.4$ bash-4.4$ git subrepo status 1 subrepo: Git subrepo 'build-system': Remote URL: ../../remote/build-system.git Upstream Ref: b2f5079 Tracking Branch: master Pulled Commit: b2f5079 Pull Parent: b5e76a7 bash-4.4$ 

O histórico do subprojeto do sistema de construção não é entregue na árvore principal; temos apenas um commit compactado, que é acompanhado por informações de segundo plano. Esta informação está sob controle de versão no arquivo ./build-system/.gitrepo/config :

 [subrepo] remote = ../../remote/build-system.git branch = master commit = b2f507918f2821cb7dd90c33223ed5cc3c9922a2 parent = b5e76a713f895565b06ee3ccfa29f19131ba06dd method = merge cmdver = 0.4.1 

Informações sobre subprojetos podem ser obtidas usando o comando git subrepo config , por exemplo, para descobrir a revisão do projeto upstream remote / build-system.git , que acabou de chegar ao repositório principal, usando o comando:

 bash-4.4$ bash-4.4$ git subrepo config build-system commit Subrepo 'build-system' option 'commit' has value 'b2f507918f2821cb7dd90c33223ed5cc3c9922a2'. bash-4.4$ 

Deve-se mencionar que o pacote git-subrepo original não salva informações sobre subprojetos no arquivo .gitrepo / config , mas no arquivo .gitrepo .

Portanto, obtivemos a versão mais recente da ramificação principal do repositório upstream remote / build-system.git e a colocamos no subdiretório build-system do projeto da plataforma principal.

Para entregar essas alterações no repositório upstream remote / platform.git , o autor precisa executar o comando git push :

 bash-4.4$ bash-4.4$ git push Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 4 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 849 bytes | 849.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git <font color="#8b0000">b5e76a7..6b831e4</font> master -> master bash-4.4$ 

Mais informações sobre os comandos git subrepo podem ser obtidas no arquivo ReadMe.pod ou na linha de comando

 bash-4.4$ git subrepo help <command> 

por exemplo:

 bash-4.4$ git subrepo help clone 

Considere agora tudo o que acontece com o usuário.

Obtendo código pelos usuários

No momento, quando o usuário ainda não recebeu uma atualização para o repositório upstream platform.git , sua cópia contém um arquivo README

 bash-4.4$ bash-4.4$ cd user/platform/ bash-4.4$ ls README bash-4.4$ 

contendo uma linha:

 bash-4.4$ bash-4.4$ cat README [master] platform 1.0.0 bash-4.4$ 

Depois de quebrar as alterações do repositório upstream

 bash-4.4$ bash-4.4$ git pull remote: Enumerating objects: 7, done. remote: Counting objects: 100% (7/7), done. remote: Compressing objects: 100% (4/4), done. remote: Total 6 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (6/6), done. From /home/prog/0.4.1/remote/platform b5e76a7..6b831e4 master -> origin/master Updating <font color="#8b0000">b5e76a7..6b831e4</font> Fast-forward build-system/.gitrepo/config | 12 ++++++++++++ build-system/README | 3 +++ 2 files changed, 15 insertions(+) create mode 100644 build-system/.gitrepo/config create mode 100644 build-system/README bash-4.4$ 

o usuário terá à sua disposição o código do subprojeto do sistema de compilação exatamente dessa revisão, que foi determinada pelo autor do projeto. O usuário pode atualizar a revisão atual a qualquer momento usando o comando config :

 bash-4.4$ bash-4.4$ git subrepo config build-system/ commit Subrepo 'build-system' option 'commit' has value 'b2f507918f2821cb7dd90c33223ed5cc3c9922a2'. bash-4.4$ 

Vale ressaltar que o usuário não precisa fazer configurações adicionais e pode confiar no fato de que o autor do projeto deu a ele exatamente a revisão do sistema de compilação necessária para que a versão atual da plataforma funcione.

É exatamente isso que o autor do projeto buscou.

Entregar alterações em um projeto upstream

Suponha agora que nosso usuário seja membro do projeto e tenha permissão para entregar alterações não apenas no repositório upstream remote / platform.git , mas também no repositório upstream do subprojeto remote / build-system.git .

Então, se o usuário fizer as alterações:

 bash-4.4$ bash-4.4$ cd build-system/ bash-4.4$ vim README bash-4.4$ cat README [master] build-system 1.0.1 bash-4.4$ bash-4.4$ git commit -a -m "update BS version to 1.0.1" [master d30b001] update BS version to 1.0.1 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ bash-4.4$ cd .. bash-4.4$ git log commit d30b001286b08708f5c30c1f5346a90e4339f969 (HEAD -> master) Author: user <___@_____> Date: Tue Oct 30 10:49:32 2018 +0300 update BS version to 1.0.1 . . . bash-4.4$ 

ele poderá colocá-los em repositórios upstream da seguinte maneira:

 bash-4.4$ bash-4.4$ git subrepo push build-system/ Subrepo 'build-system' pushed to '../../remote/build-system.git' (master). bash-4.4$ 

 bash-4.4$ bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ bash-4.4$ git push Enumerating objects: 14, done. Counting objects: 100% (14/14), done. Delta compression using up to 4 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (9/9), 992 bytes | 992.00 KiB/s, done. Total 9 (delta 1), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git d00be9f..deccb66 master -> master bash-4.4$ 

Trabalho direto com repositório upstream

Agora considere o que aconteceu no repositório upstream remote / build-system.git

 bash-4.4$ bash-4.4$ cd owner/build-system/ bash-4.4$ bash-4.4$ git pull remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /home/prog/0.4.1/remote/build-system b2f5079..d229920 master -> origin/master Updating b2f5079..d229920 Fast-forward README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ bash-4.4$ git log commit d229920c7de34405bc7b8d47f36d420987687908 (HEAD -> master, origin/master) Author: user <___@_____> Date: Tue Oct 30 10:49:32 2018 +0300 update BS version to 1.0.1 commit b2f507918f2821cb7dd90c33223ed5cc3c9922a2 Author: user <___@_____> Date: Tue Oct 30 10:05:30 2018 +0300 init build-system master 1.0.0 bash-4.4$ 

Ou seja, o autor do projeto recebeu as alterações feitas pelo participante do projeto.

Obviamente, o autor pode fazer alterações diretamente no repositório upstream do projeto do sistema de compilação :

 bash-4.4$ bash-4.4$ cd owner/build-system/ bash-4.4$ bash-4.4$ vim README bash-4.4$ cat README [master] build-system 1.0.2 bash-4.4$ git commit -a -m "update build-system version to 1.0.2" [master 8255f59] update build-system version to 1.0.2 1 file changed, 1 insertion(+), 1 deletion(-) bash-4.4$ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Writing objects: 100% (3/3), 281 bytes | 281.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To /home/prog/0.4.1/remote/build-system.git d229920..8255f59 master -> master bash-4.4$ 

E todos os participantes, assim como os usuários do projeto principal, poderão receber essas alterações usando o comando git subrepo pull

 bash-4.4$ bash-4.4$ cd owner/platform/ bash-4.4$ bash-4.4$ git subrepo pull build-system/ Subrepo 'build-system' pulled from '../../remote/build-system.git' (master). bash-4.4$ git status On branch master Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree clean bash-4.4$ git push Enumerating objects: 11, done. Counting objects: 100% (11/11), done. Delta compression using up to 4 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 670 bytes | 670.00 KiB/s, done. Total 6 (delta 1), reused 0 (delta 0) To /home/prog/0.4.1/remote/platform.git 6b831e4..b6f4a7b master -> master bash-4.4$ 

Conclusões

Se o desenvolvedor não precisar armazenar o histórico de subprojetos no repositório principal e, ao fornecer o código, ele operar com ramificações em vez de com tags fixas, o git-subrepo será adequado para organizar o trabalho diário.

Condicionalmente, uma das desvantagens do git-subrepo é o fato de que a operação do clit do git subrepo é possível apenas em relação às ramificações do subprojeto. Em outras palavras, o usuário não pode conectar o subprojeto referente à sua marca fixa ou a uma revisão específica, ou seja, comandos como

 bash-4.4$ git subrepo clone ../../remote/build-system.git build-system -t 1.0.1 bash-4.4$ git subrepo clone ../../remote/build-system.git build-system 7f5d1113eb0bc6 

inválido.

LITERATURA:

• Git - fusão de subárvore
• Dominando subárvores git
• Dominando submódulos git
• Git subrepo
• O modelo de gerenciamento de ramificação e módulo git para um projeto grande