Esta página do GitPro resume bem as consequências de uma atualização do sub-módulo git
Quando você executa git submodule update, ele faz check-out da versão específica do projeto, mas não dentro de uma ramificação. Isso é chamado de ter uma cabeça desanexada - significa que o arquivo HEAD aponta diretamente para uma confirmação, não para uma referência simbólica.
O problema é que geralmente você não deseja trabalhar em um ambiente desanexado, porque é fácil perder alterações .
Se você fizer uma atualização inicial do sub-módulo, confirme nesse diretório de sub-módulo sem criar uma ramificação para trabalhar e execute a atualização do sub-módulo git novamente a partir do superprojeto sem confirmar, o Git substituirá suas alterações sem avisar. Tecnicamente, você não perderá o trabalho, mas não terá um ramo apontando para ele, por isso será um pouco difícil de recuperar.
Nota de março de 2013:
Como mencionado em " git submódulo mais recente ", um submódulo agora (git1.8.2) pode rastrear uma ramificação.
# add submodule to track master branch
git submodule add -b master [URL to Git repo];
# update your submodule
git submodule update --remote
# or (with rebase)
git submodule update --rebase --remote
Veja " git submodule update --remotevsgit pull ".
A resposta do MindTooth ilustra uma atualização manual (sem configuração local):
git submodule -q foreach git pull -q origin master
Nos dois casos, isso alterará as referências dos submódulos (o gitlink , uma entrada especial no índice do repositório pai ), e você precisará adicionar, confirmar e enviar as referências do repositório principal.
Da próxima vez que você clonar esse repositório pai, ele preencherá os submódulos para refletir essas novas referências SHA1.
O restante desta resposta detalha o recurso clássico do submódulo (referência a um commit fixo , que é o ponto principal da noção de submódulo).
Para evitar esse problema, crie uma ramificação ao trabalhar em um diretório de submodule com git checkout -b work ou algo equivalente. Quando você faz a atualização do submódulo pela segunda vez, ele ainda reverte seu trabalho, mas pelo menos você tem um ponteiro para retornar.
Alternar ramificações com submódulos também pode ser complicado. Se você criar uma nova ramificação, adicionar um submódulo lá e voltar para uma ramificação sem esse submódulo, você ainda terá o diretório do submódulo como um diretório não rastreado:
Então, para responder suas perguntas:
posso criar ramificações / modificações e usar push / pull como faria em repositórios regulares ou há coisas a serem cautelosas?
Você pode criar uma ramificação e enviar modificações.
AVISO (do Tutorial do Git Submodule ): Sempre publique (envie) a alteração do submódulo antes de publicar (envie) a alteração no superprojeto que o referencia. Se você esquecer de publicar a alteração do submódulo, outros não poderão clonar o repositório.
como eu avançaria o commit do submódulo referenciado de say (tagged) 1.0 para 1.1 (mesmo que o chefe do repo original já esteja em 2.0)
A página " Entendendo os submódulos " pode ajudar
Os submódulos Git são implementados usando duas partes móveis:
- o
.gitmodulesarquivo e
- um tipo especial de objeto de árvore.
Juntos, eles triangulam uma revisão específica de um repositório específico, que é registrada em um local específico no seu projeto.
Na página do submódulo git
você não pode modificar o conteúdo do submódulo de dentro do projeto principal
100% correto: você não pode modificar um submódulo, consulte apenas um de seus commit.
É por isso que, quando você modifica um submódulo de dentro do projeto principal, você:
- precisa confirmar e enviar dentro do submódulo (para o módulo upstream) e
- em seguida, suba em seu projeto principal e confirme novamente (para que o projeto principal se refira ao novo submódulo que você acabou de criar e enviar)
Um submódulo permite que você desenvolva uma abordagem baseada em componentes , onde o projeto principal se refere apenas a confirmações específicas de outros componentes (aqui "outros repositórios Git declarados como submódulos").
Um submódulo é um marcador (confirmação) para outro repositório Git que não é vinculado pelo ciclo principal de desenvolvimento do projeto: ele (o "outro" repositório Git) pode evoluir independentemente.
Cabe ao projeto principal escolher desse outro repositório qualquer que seja a confirmação necessária.
No entanto, se você quiser, por conveniência , modificar um desses submódulos diretamente do seu projeto principal, o Git permite que você faça isso, desde que você primeiro publique essas modificações do submódulo no repositório original do Git e, em seguida, comprometa seu projeto principal, referindo-se a uma nova versão do referido submódulo.
Mas a idéia principal permanece: referenciar componentes específicos que:
- tem seu próprio ciclo de vida
- tem seu próprio conjunto de tags
- tem seu próprio desenvolvimento
A lista de confirmações específicas às quais você está se referindo no seu projeto principal define sua configuração (é disso que se trata o Gerenciamento de Configurações , englobando apenas o Sistema de Controle de Versão )
Se um componente pudesse realmente ser desenvolvido ao mesmo tempo que o projeto principal (porque qualquer modificação no projeto principal envolveria a modificação do subdiretório e vice-versa), seria um "submódulo" não mais, mas um mesclagem de subárvore (também apresentada na pergunta Transferindo a base de código herdada do cvs para o repositório distribuído ), vinculando o histórico dos dois repositórios Git.
Isso ajuda a entender a verdadeira natureza dos submódulos do Git?