O Blog GitHub

eventualmente, qualquer projeto de software interessante virá a depender de outro projeto, biblioteca ou framework. O Git fornece submódulos para ajudar com isso. Os submódulos permitem-lhe incluir ou incorporar um ou mais repositórios como uma sub-pasta dentro de outro repositório.

para muitos projetos, submódulos não são a melhor resposta (mais sobre isso abaixo), e mesmo no seu melhor, trabalhar com submódulos pode ser complicado, mas vamos começar por olhar um exemplo para a frente.,

adicionando um submódulo

digamos que está a trabalhar num projecto chamado Slingshot. Você tem código para y-shaped stick e a rubber-band.


flickr foto compartilhada pelo jovem@arte sob uma licença Creative Commons ( BY ) licença

Ao mesmo tempo, em outro repositório, você tem outro projeto chamado Rock—é apenas um genérico rock biblioteca, mas você acha que seria perfeito para o Estilingue.

pode adicionar rock como submódulo de slingshot., slingshot repositório:

neste ponto, você vai ter uma rock pasta dentro de slingshot, mas se você fosse para espreitar para dentro dessa pasta, dependendo da sua versão do Git, você pode ver … nada.,

as versões mais Recentes do Git irá fazer isso automaticamente, mas versões mais antigas vai exigir que você indicar explicitamente o Git para baixar o conteúdo de rock:

Se tudo parece bom, você pode confirmar isso mudar e você vai ter uma rock pasta slingshot repositório com todo o conteúdo de rock repositório.,

No GitHub, o rock ícone de pasta vai ter um pouco de indicador mostrando que é um sub-módulo:

E clicar em rock pasta irá levá-lo para o rock repositório.é isso! Você incorporou o repositório rock dentro do repositório slingshot. Você pode interagir com todo o conteúdo de rock como se fosse uma pasta dentro de slingshot (pois é).,

Na linha de comando, o Git comandos emitidos a partir de slingshot (ou qualquer uma das outras pastas, rubber-band e y-shaped-stick) irão operar no “repositório pai”, slingshot mas os comandos problema a partir de rock pasta vai operar apenas o rock repositório:

Aderir a um projeto usando submódulos

Agora, dizer que você é um novo colaborador ingressar Projeto Estilingue., Você começaria por executar git clonepara baixar o conteúdo do repositório slingshot. Neste ponto, se você fosse espreitar dentro da pasta rock, você veria … nada.

Mais uma vez, o Git espera que lhe peçamos explicitamente que baixe o conteúdo do submódulo., Você pode usar git submodule update --init --recursive aqui também, mas se você está clonagem slingshot pela primeira vez, você pode usar uma versão modificada clone comando para garantir que você baixar tudo, incluindo qualquer submódulos:

mudar para submódulos

Ele pode ser um pouco complicada para tomar uma subpasta existente e transformá-lo em uma dependência externa. Vejamos um exemplo.

Você está prestes a iniciar um novo projeto-uma lata mágica roll-back–que também precisa de um rubber-band., Vamos pegar o rubber-band que você construiu para slingshot, dividi-lo em um repositório independente, e depois incorporá-lo em ambos os projetos através de submódulos.

Você pode tirar tudo da pasta do projeto Slingshot’s rubber-band e extraí-lo para um novo repositório e até mesmo manter o histórico de commit.

Let’s begin by extracting the contents of therubber-band folder out ofslingshot., Você pode usar git filter-branchpara fazer isso, deixando-o apenas com os commits relacionados com rubber-band. O comando git filter-branch irá reescrever a história do nosso repositório, fazendo com que pareça que a pasta

tinha sido sempre o seu próprio repositório. Para mais informações sobregit filter-branch, ver este artigo.

O primeiro passo é fazer uma cópia de slingshot trabalhar—a meta final é de rubber-band para ficar como o seu próprio repositório, de forma a deixar slingshot como está., Você pode usar cp com -r recursivamente cópia do inteiro slingshot para uma nova pasta rubber-band.,

parece Que rubber-band é apenas outro slingshot, mas agora, a partir de rubber-band repositório, execute git filter-branch:

neste ponto, você vai ter uma pasta rubber-band, que é um repositório que tipo de semelhante Projeto de Estilingue, mas ele só tem os arquivos e cometer história a partir de rubber-band pasta.,

Uma vez que copiou isto deslingshot, o novo repositório terá à mesma quaisquer ramificações de localização remota que tenha configurado quando eraslingshot. Você não quer empurrar rubber-bandde volta paraslingshot. Você quer empurrar isso para um novo repositório.

crie um novo repositório para rubber-bandno GitHub, então atualize o remoto pararubber-band., Supondo que você estivesse ligando remoto origin, você pode:

em Seguida, você pode publicar o novo genérico “de banda de borracha módulo” com git push.,

Agora que você já separados rubber-band em seu próprio repositório, você precisa excluir o antigo rubber-band pasta de slingshot repositório:

atualizar slingshot use rubber-band como um sub-módulo:

Como vimos antes, quando estávamos adicionando rock agora temos um repositório um repositório., Três repositórios, na verdade: o “pai” do repositório slingshot, mais os dois “sub” repositórios, rock e rubber-band.

além disso, se mergulharmos de volta para o histórico de slingshot, veremos os commits que fizemos originalmente em rubber-band de volta quando era uma pasta—a exclusão da pasta não apagou nenhum do histórico., Isto às vezes pode ser um pouco confuso—uma vez que o repositório de”criança”tem uma versão copiada e modificada daqueles antigos commits

, às vezes pode parecer que você está tendo déja vu.

infelizmente, qualquer colaborador que puxe slingshot neste ponto terá uma pasta vazia rubber-band., Convém lembrar que seus colaboradores para executar esse comando para garantir que eles tenham todo o submódulo de conteúdo:

Você também vai querer adicionar o rubber-band submódulo para magic roll-back can. Felizmente, tudo o que você precisa fazer é seguir o mesmo procedimento utilizado anteriormente, quando você adicionou rock slingshot, em “Adicionar um sub-módulo.”

conselhos sobre a utilização de submódulos (ou não)

  • Antes de adicionar um repositório como submódulo, primeiro verifique se tem uma alternativa melhor disponível., Os submódulos Git funcionam bem o suficiente para casos simples, mas hoje em dia existem muitas vezes melhores ferramentas disponíveis para gerenciar dependências do que os submódulos Git podem oferecer. Línguas modernas como Go têm sistemas de gestão de dependências amigáveis e conscientes do Git desde o início. Outros, como rubigemas da Ruby, nó.o npm da js, ou CocoaPods da Cocoa e Carthage, foram adicionados pela comunidade de programação. Até os desenvolvedores front-end têm ferramentas como Bower para gerenciar bibliotecas e frameworks para JavaScript e CSS.
  • lembre-se que o Git não transfere o conteúdo do submódulo por omissão., Se você estiver adicionando um sub-módulo para um projeto existente, certifique-se de alguém que trabalha no projeto sabe que eles precisam para executar comandos como git submodule update e git clone --recursive para garantir que eles obtêm tudo, e isso inclui qualquer implantação automatizada ou serviço de testes que podem estar envolvidos no projeto! Recomendamos que você use algo como nossos Scripts para governá-los a todos para garantir que todos os colaboradores e serviços tenham acesso ao mesmo conteúdo do repositório em todos os lugares.submódulos requerem um equilíbrio cuidadoso entre consistência e conveniência., A configuração usada aqui prefere consistência, ao custo de um pouco de conveniência. Geralmente é melhor ter os submódulos de um projeto presos a um SHA específico, para que todos os colaboradores recebam o mesmo conteúdo. Mas esta configuração também torna difícil para os desenvolvedores no repositório “pai” contribuir com mudanças de volta para o repositório submódulo.
  • lembre—se que os colaboradores não verão automaticamente atualizações em submódulos-se você atualizar um submódulo, você pode precisar lembrar seus colegas para executar git submodule update ou eles provavelmente verão comportamento estranho.,
  • gerir repositórios dinâmicos, em rápida evolução ou fortemente co-dependentes com submódulos pode rapidamente tornar-se frustrante. Este post foi focado em relações simples, relativamente estáticas pai-filho repositório. Um post de acompanhamento futuro irá detalhar algumas estratégias para ajudar a gerenciar fluxos de trabalho mais complexos submódulos.

Leitura Adicional

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *