Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.47.1 no changes
- 2.47.0 10/06/24
- 2.44.1 → 2.46.2 no changes
- 2.44.0 02/23/24
- 2.42.1 → 2.43.5 no changes
- 2.42.0 08/21/23
- 2.36.1 → 2.41.2 no changes
- 2.36.0 04/18/22
- 2.28.1 → 2.35.8 no changes
- 2.28.0 07/27/20
- 2.26.1 → 2.27.1 no changes
- 2.26.0 03/22/20
- 2.25.2 → 2.25.5 no changes
- 2.25.1 02/17/20
- 2.25.0 01/13/20
- 2.24.1 → 2.24.4 no changes
- 2.24.0 11/04/19
- 2.22.1 → 2.23.4 no changes
- 2.22.0 06/07/19
- 2.19.1 → 2.21.4 no changes
- 2.19.0 09/10/18
- 2.18.1 → 2.18.5 no changes
- 2.18.0 06/21/18
- 2.17.0 → 2.17.6 no changes
- 2.16.6 12/06/19
- 2.15.4 no changes
- 2.14.6 12/06/19
- 2.13.7 05/22/18
- 2.12.5 09/22/17
- 2.11.4 no changes
- 2.10.5 09/22/17
- 2.9.5 07/30/17
- 2.8.6 07/30/17
- 2.7.6 no changes
- 2.6.7 05/05/17
- 2.5.6 no changes
- 2.4.12 05/05/17
- 2.3.10 09/28/15
- 2.1.4 → 2.2.3 no changes
- 2.0.5 12/17/14
RESUMO
git submodule [--quiet] [--cached] git submodule [--quiet] add [<opções>] [--] <repository> [<caminho>] git submodule [--quiet] status [--cached] [--recursive] [--] [<caminho>…] git submodule [--quiet] init [--] [<caminho>…] git submodule [--quiet] deinit [-f|--force] (--all|[--] <caminho>…) git submodule [--quiet] update [<opções>] [--] [<caminho>…] git submodule [--quiet] set-branch [<opções>] [--] <caminho> git submodule [--quiet] set-url [--] <caminho> <newurl> git submodule [--quiet] summary [<opções>] [--] [<caminho>…] git submodule [--quiet] foreach [--recursive] <command> git submodule [--quiet] sync [--recursive] [--] [<caminho>…] git submodule [--quiet] absorbgitdirs [--] [<caminho>…]
DESCRIÇÃO
Inspeciona, atualiza e gerencia os submódulos.
Para mais informações sobre submódulos, consulte gitsubmodules[7].
COMANDOS
Sem argumentos, mostra a condição geral dos submódulos existentes. Vários subcomandos estão disponíveis para realizar operações nos submódulos.
- add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--ref-format <format>] [--depth <depth>] [--] <repository> [<path>]
-
Adicione o repositório informado como um submódulo no caminho especificado ao conjunto de alterações para ser feito o commit ao lado do projeto atual: o projeto atual é chamado de "superproject".
<repositório> é a URL do repositório de origem do novo submódulo. Pode ser uma URL absoluta ou (se começar com ./ ou ../), o local relativo ao repositório remoto padrão do superprojeto (observe que, para especificar um repositório foo.git onde está localizado um superprojeto bar.git, você terá que usar
../foo.git
em vez de./foo.git
- como seria de se esperar ao seguir as regras para URLs relativas - porque a avaliação de URLs relativas no Git é idêntica à de diretórios relativos).O ramo remoto padrão é o ramo remote do ramo rastreado remotamente no ramo atual. Se não houver uma ramificação de rastreamento remoto ou se o
HEAD
for desanexado, a origin será considerada o ramo remoto predefinido. Se o superprojeto não tiver um ramo remoto predefinido configurado, o superprojeto será o seu próprio topo autoritativo e o diretório de trabalho atual será usado em seu lugar.O argumento opcional
<caminho>
é o local relativo para que o submódulo clonado exista no superprojeto. Caso o<caminho>
não seja informado, a parte canônica do repositório da origem será utilizada ("repo" para o "/path/to/repo.git" e "foo" para o "host.xz:foo/.git"). Caso o<caminho>
exista e já for um repositório Git válido, ele será preparado para o commit sem clonagem. O<caminho>
também é utilizado como o nome lógico do sub-módulo nas suas entradas de configuração, a menos que--name
seja utilizado para definir um nome lógico.A URL informada é registrado em
.gitmodules
para ser usado por usuários subsequentes que clonarem o superprojeto. Se a URL for informada em relação ao repositório do superprojeto, presume-se que os repositórios do superprojeto e do submódulo serão mantidos juntos no mesmo local relativo, e somente o URL do superprojeto precisará ser fornecido. O git-submodule localizará corretamente o submódulo usando a URL relativa em.gitmodules
.If
--ref-format <format>
is specified, the ref storage format of newly cloned submodules will be set accordingly. - status [--cached] [--recursive] [--] [<caminho>…]
-
Exiba a condição geral dos submódulos. Irá exibir o SHA-1 do commit registrado atualmente para cada submódulo, junto com o caminho do submódulo e a saída do comando git description para o SHA-1. Cada SHA-1 provavelmente será prefixado com
-
caso o submódulo não seja inicializado,+
caso o commit verificado do submódulo atual não coincida com o SHA-1 encontrado no índice do repositório que contenha oU
caso o submódulo tenha conflitos de mesclagem.Caso a opção
--cached
seja utilizado, este comando exibirá o SHA-1 registrado no superprojeto para cada sub-módulo.Caso
--recursive
seja utilizado, este comando será recusado no submódulos aninhados e exibirá a sua condição geral também.Caso apenas tenha interesse nas alterações dos submódulos inicializados no momento em relação ao commit registrado no índice ou no HEAD, o git-status[1] e o git-diff[1] também disponibilizarão essas informações (e podem também relatar as alterações na árvore de trabalho de um submódulo).
- init [--] [<caminho>…]
-
Inicialize os submódulos registrados no índice (que foram adicionados e confirmados em outro lugar) definindo
submodule.$name.url
em.git/config
, usando a mesma configuração de.gitmodules
como modelo. Se o URL for relativo, ele será resolvido usando o ramo remoto padrão. Se não houver um ramo remoto padrão, o repositório atual será considerado upstream.Os argumentos opcionais
<caminho>
limitam onde os submódulos serão inicializados. Se nenhum caminho for especificado e osubmodule.active
tiver sido configurado, os submódulos configurados para estarem ativos serão inicializados; caso contrário, todos os submódulos serão inicializados.Ele também copiará o valor de
submodule.$name.update
, se estiver presente no arquivo.gitmodules
, para.git/config
, mas (1) esse comando não altera as informações existentes em.git/config
e (2)submodule.$name.update
definido como um comando personalizado não é copiado por motivos de segurança.Em seguida, você pode personalizar os URLs do clone do submódulo em
.git/config
para a sua configuração local e prosseguir comgit submodule update
; você também pode usargit submodule update --init
sem a etapa init explícita se não tiver a intenção de personalizar nenhum local do submódulo.Consulte o subcomando
add
para obter a definição predefinida do ramo remoto. - deinit [-f|--force] (--all|[--] <caminho>…)
-
Cancele o registro dos submódulos informado, ou seja, remova toda a seção
submodule.$name
do.git/config
junto com a sua árvore de trabalho. Outras futuras chamadas para o comandogit submodule update
,git submodule foreach
egit submodule sync
irão ignorar todos os submódulos não registrados até que sejam inicializados novamente, então utilize este comando caso não queira mais fazer uma verificação do submódulo na sua árvore de trabalho local.O comando exibe um erro quando for executado sem o
pathspec
em vez de cancelar a inicialização de tudo, evitando erros.Caso
--force
seja utilizado, a árvore de trabalho do submódulo será removida, mesmo que contenha alterações locais.Caso realmente deseja remover um submódulo do repositório e fazer o commit em vez disso utilize git-rm[1] Para opções de remoção consulte gitsubmodules[7].
- update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--ref-format <format>] [--depth <depth>] [--recursive] [--jobs <n>] [--[no-]single-branch] [--filter <filter-spec>] [--] [<path>…]
-
Atualize os submódulos registrados para que correspondam ao que o superprojeto espera, clonando os submódulos ausentes, obtendo os commits ausentes nos submódulos e atualizando a árvore de trabalho dos submódulos. A "atualização" pode ser feita de várias maneiras, dependendo das opções da linha de comando e do valor da variável de configuração
submodule.<nome>.update
. A opção de linha de comando tem precedência sobre a variável de configuração. Se nenhum dos dois for fornecido, será realizado um checkout. (Observação: o que está no arquivo.gitmodules
é irrelevante neste momento; consulte o comandogit submodule init
acima para saber como o.gitmodules
é usado). Os procedimentos de atualização update compatíveis tanto com a linha de comando quanto com a configuraçãosubmodule.<nome>.update
são:- checkout
-
o commit registrado no superprojeto será verificado no submódulo do HEAD desanexado.
Caso a opção
--force
utilizado, o submódulo será averiguado (utilizandogit checkout --force
), mesmo que o commit definido no índice do repositório que o contenha já coincida com os commits que já foram verificados. - rebase
-
a fundação do submódulo do ramo atual será refeito no commit registrado no superproject.
- merge
-
o commit registrado no superprojeto será mesclado no submódulo do ramo atual.
Os procedimentos de atualização a seguir têm limitações adicionais:
- comando personalizado
-
para executar comandos arbitrários com o ID do commit como argumento. Especificamente, se a variável de configuração
submodule.<nome>.update
for definida como!custom command
, o nome do objeto do commit registrado no superprojeto para o submódulo será anexado à stringcustom command
e depois executado. Observe que esse mecanismo não é compatível com o arquivo.gitmodules
ou com a linha de comando. - none
-
o submódulo não é atualizado. Esse procedimento de atualização não é permitido na linha de comando.
Se o submódulo ainda não foi inicializado e você apenas deseja utilizar a configuração armazenada no
.gitmodules
, você pode inicializar automaticamente o submódulo com a opção--init
.Caso a opção
--recursive
seja utilizada, este comando recursará nos submódulos registrados e atualizará todos os submódulos aninhados.If
--ref-format <format>
is specified, the ref storage format of newly cloned submodules will be set accordingly.Se a opção
--filter <spec-do-filtro>
for especificado, o filtro de clone parcial fornecido será aplicado ao submódulo. Consulte o git-rev-list[1] para obter detalhes sobre as especificações do filtro. - set-branch (-b|--branch) <ramo> [--] <caminho>
- set-branch (-d|--default) [--] <caminho>
-
Define o submódulo como predefinido nos ramos monitorados remotamente. A opção
--branch
permite que o nome do ramo remoto seja definido. A opção--default
remove a chave da configuraçãosubmodule.<nome>.branch
, que faz com que a predefinição do ramo monitorado seja o HEAD remoto. - set-url [--] <caminho> <newurl>
-
Define a URL do submódulo informado para
<newurl>
. Em seguida, sincronize automaticamente a nova configuração da URL remota do submódulo. - summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<caminho>…]
-
Exiba o resumo do commit entre o commit informado (a predefinição retorna para
HEAD
) e a árvore de trabalho/índice. Para um submódulo em questão, são exibidas uma série de commit do submódulo entre o commit do super projeto e o índice ou a árvore de trabalho (alternada por--cached
). Caso a opção--files
seja utilizada, exiba a série dos commits no submódulo entre o índice do super projeto e a árvore de trabalho do submódulo (esta opção não permite a utilização da opção--cached
ou para informar um commit de forma explícita).O uso da opção
--submodule=log
com git-diff[1] também fornecerá estas informações. - foreach [--recursive] <comando>
-
Avalia um comando de shell arbitrário em cada submódulo verificado. O comando tem acesso às variáveis
$name
,$sm_path
,$displaypath
,$sha1
e$toplevel
: O$name
é o nome da seção relevante do submódulo em.gitmodules
,$sm_path
é o caminho do submódulo conforme registrado no superprojeto imediato,$displaypath
contém o caminho relativo do diretório de trabalho atual para o diretório raiz do submódulo,$sha1
é o commit conforme registrado no superprojeto imediato e$toplevel
é o caminho absoluto para o topo imediato do superprojeto. Observe que, para evitar conflitos com$PATH
no Windows, a variável$path
agora é um sinônimo obsoleto da variável$sm_path
. Todos os submódulos definidos no superprojeto, mas que não tenham sido verificados, são ignorados por esse comando. A menos que seja informado a opção--quiet
, o foreach imprime o nome de cada submódulo antes de avaliar o comando. Se a opção--recursive
for usada, os submódulos serão percorridos recursivamente (ou seja, o comando do shell fornecido também será avaliado nos submódulos aninhados). Um retorno diferente de zero do comando em qualquer submódulo faz com que o processamento seja encerrado. Isso pode ser substituído pela adição de || : ao final do comando.Como um exemplo, o comando abaixo exibirá o caminho e a averiguação atual do commit para cada submódulo:
git submodule foreach 'echo $sm_path `git rev-parse HEAD`'
- sync [--recursive] [--] [<caminho>…]
-
Sincroniza a configuração da URL remota dos submódulos com o valor definido em
.gitmodules
. Afetará apenas os submódulos que já possuem uma entrada da URL no.git/config
(é o caso quando eles são inicializados ou foram adicionados recentemente). É útil quando as URLs do submódulo mudam a upstream e você precisa atualizar os seus repositórios locais de acordo.O comando
git submodule sync
sincroniza todos os submódulos enquanto o comandogit submodule sync - A
sincroniza apenas o submódulo "A".Caso a opção
--recursive
seja utilizada, este comando recursará nos submódulos registrados e sincronizará todos os submódulos aninhados. - absorbgitdirs
-
Caso um diretório git de um submódulo estiver dentro dele, mova o diretório git do submódulo para o caminho
$GIT_DIR/modules
do superprojeto, conecte o diretório git, o seu diretório de trabalho, definindocore.worktree
e adicionando um Arquivo .git apontando para o diretório git incorporado no diretório git dos superprojetos.Um repositório que foi clonado de forma independente e posteriormente adicionado como um submódulo ou com configurações antigas, que possua o diretório git dentro do submódulo, em vez de estar incorporado ao diretório git dos superprojetos.
A predefinição deste comando é ser recursivo.
OPÇÕES
- -q
- --quiet
-
Exiba apenas as mensagens de erro.
- --progress
-
Essa opção só é válida para o comando
add
eupdate
. A condição geral do progresso é relatada no fluxo de erro padrão por padrão quando ele é anexado a um terminal, a menos que a opção-q
seja especificada. Esta opção impõem a condição geral de progresso, ainda que o fluxo de erro predefinido não seja direcionado a um terminal. - --all
-
Esta opção só é válida para o comando
deinit
. Cancele o registro de todos os submódulos na árvore de trabalho. - -b <ramo>
- --branch <ramo>
-
O ramo do repositório que será adicionado como um submódulo. O nome do ramo é gravado como
submodule.<nome>.branch
em.gitmodules
paraupdate --remote
. Um valor especial.
é usado para indicar que o nome do ramo no submódulo deve ser o mesmo nome do ramo atual no repositório atual. Se a opção não for especificada, a predefinição é oHEAD
remoto. - -f
- --force
-
Esta opção só é válida para os comandos
add
,deinit
eupdate
. Ao executaradd
, permite adicionar um caminho de submódulo que de outra forma seria ignorado. Ao executar o deinit, as árvores de trabalho do submódulo serão removidas mesmo que contenham alterações locais. Ao executar oupdate
(apenas eficaz com o procedimento de checkout), descarte as alterações locais nos submódulos ao mudar para um commit diferente; e execute sempre uma operação de checkout no submódulo, mesmo que o commit listado no índice do repositório que o contém corresponda ao commit verificado no submódulo. - --cached
-
Esta opção só é válida para os comandos
status`e `summary
. Esses comandos normalmente usam o commit encontrado no submóduloHEAD
, mas com essa opção, o commit armazenado no índice é usado. - --files
-
Esta opção só é válida para o comando
summary
. Quando esta opção é utilizada o comando compara o commit no índice em conjunto com o que está no submóduloHEAD
. - -n
- --summary-limit
-
Esta opção só é válida para o comando
summary
. Limitar o tamanho do resumo summary (quantidade de commits mostrados no total). Usar 0 desativará o resumo summary; um número negativo significa ilimitado (o padrão). Este limite só se aplica aos submódulos alterados. O tamanho é sempre limitado a 1 para submódulos adicionados/excluídos/alterados por tipo. - --remote
-
Esta opção só é válida para o comando
update
. Em vez de usar o SHA-1 registrado do superprojeto para atualizar o submódulo, use a condição do submódulo da ramificação rastreada remotamente. O "remoto" usado é o ramo da ramificação remota (branch.<nome>.remote
), cujo padrão éorigin
. A ramificação remota usada tem como padrão oHEAD
remoto, mas o nome da ramificação pode ser substituído pela configuração da opçãosubmodule.<nome>.branch
em.gitmodules
ou.git/config
(tendo precedência o.git/config
).Isso funciona para qualquer um dos procedimentos de atualização compatíveis (
--checkout
,--rebase
, etc.). A única alteração é a origem do SHA-1 de destino. Por exemplo, a opçãosubmodule update --remote --merge
mesclará as alterações do submódulo upstream nos submódulos, enquanto a opçãosubmodule update --merge
mesclará as alterações do gitlink do superprojeto nos submódulos.Para garantir a condição atual da ramificação de rastreamento, a opção
update --remote
busca pelo repositório remoto do submódulo antes de calcular o SHA-1. Se não quiser buscar, você deve usar a opçãosubmodule update --remote --no-fetch
.Use esta opção para integrar as alterações do subprojeto upstream com o
HEAD
atual do seu submódulo. Como alternativa, você pode executar ogit pull
a partir do submódulo, o que é equivalente, exceto pelo nome do ramo remoto: a opçãoupdate --remote
usa o repositório upstream predefinido e osubmodule.<nome>.branch
, enquanto o comandogit pull
usa obranch.<nome>.merge
do submódulo. Prefirasubmodule.<nome>.branch
se quiser distribuir o ramo upstream predefinido com o superprojeto ebranch.<nome>.merge
se quiser uma sensação mais nativa ao trabalhar no próprio submódulo. - -N
- --no-fetch
-
Esta opção só é válida para o comando
update
. Não busque novos objetos no site remoto. - --checkout
-
Esta opção só é válida para o comando
update
. Faça o checkout do commit registrado no superprojeto numHEAD
desanexado no submódulo. Esse é o comportamento predefinido; o principal uso dessa opção é substituirsubmodule.$name.update
quando definido com um valor diferente docheckout
. Se a chavesubmodule.$name.update
não estiver explicitamente definida ou estiver definida comocheckout
, essa opção será implícita. - --merge
-
Esta opção só é válida para o comando
update
. Mesclar o commit registrado no superprojeto na ramificação atual do submódulo. Se essa opção for fornecida, oHEAD
do submódulo não será desanexado. Se uma falha de mesclagem impedir este processo, você terá que resolver os conflitos resultantes dentro do submódulo com as ferramentas usuais de resolução de conflitos. Se a chavesubmodule.$name.update
estiver definida comomerge
, esta opção estará implícita. - --rebase
-
Esta opção só é válida para o comando
update
. Faça o rebase do ramo atual para o commit registrado no superprojeto. Se essa opção for fornecida, oHEAD
do submódulo não será desanexado. Se uma falha de mesclagem impedir este processo, você terá que resolver estas falhas com o comando git-rebase[1]. Se a chavesubmodule.$name.update
estiver definida comorebase
, esta opção estará implícita. - --init
-
Esta opção só é válida para o comando
update
. Inicialize todos os submódulos para onde ogit submodule init
não foi chamado até o momento antes da atualização. - --name
-
Esta opção só é válida para o comando
add
. Define o nome do submódulo para a carreira de caracteres informada em vez de padronizar o seu caminho. O nome deve ser válido como um nome de diretório e não pode terminar com um /. - --reference <repositório>
-
Essa opção só é válida para o comando
add
eupdate
. Esses comandos às vezes precisam clonar um repositório remoto. Nesse caso, essa opção será encaminhada para o comando git-clone[1].OBSERVAÇÃO: Jamais utilize esta opção, a menos que você tenha lido com muita atenção as observações para git-clone[1],
--reference
,--shared
, e--dissociate
. - --dissociate
-
Essa opção só é válida para o comando
add
eupdate
. Esses comandos às vezes precisam clonar um repositório remoto. Nesse caso, essa opção será encaminhada para o comando git-clone[1].OBSERVAÇÃO: consulte a OBSERVAÇÃO sobre a opção
--reference
. - --recursive
-
Essa opção só é válida para os comandos
foreach
,update
,status
esync
. Percorrer os submódulos recursivamente. A operação é realizada não apenas nos submódulos do repositório atual, mas também em quaisquer submódulos aninhados dentro desses submódulos (e assim por diante). - --depth
-
Esta opção é válida para os comandos
add
eupdate
. Cria um clone superficial (shallow) com um histórico truncado para o número especificado de revisões. Consulte git-clone[1] - --[no-]recommend-shallow
-
Esta opção só é válida para o comando
update
. O clone inicial de um submódulo usará osubmodule.<nome>.shallow
recomendado, conforme fornecido pelo arquivo.gitmodules
predefinido. Para ignorar as sugestões, use a opção--no-recommend-shallow
. - -j <n>
- --jobs <n>
-
Esta opção só é válida para o comando
update
. Clonar os novos submódulos em paralelo com a mesma quantidade de trabalhos. A predefinição é o que estiver emsubmodule.fetchJobs
. - --[no-]single-branch
-
Esta opção só é válida para o comando
update
. Clone apejas um ramo durante a atualização:HEAD
ou um ramo especificado pela opção--branch
. - <caminho>…
-
Os caminhos para os submódulos. Quando especificada, esta opção restringirá o comando a operar apenas nos submódulos encontrados nos caminhos especificados. (Esta é uma exigência do argumento
add
).
ARQUIVOS
Ao inicializar os submódulos, um arquivo .gitmodules
no diretório do topo do repositório que o contém é usado para encontrar a URL de cada submódulo. Esta deve ser formatada da mesma forma que $GIT_DIR/config
. A chave para cada URL de submódulo é submodule.$name.url
. Para mais detalhes consulte gitmodules[5].
GIT
Parte do conjunto git[1]