(Git 2.22, Q2 2019, lançado git submodule set-branch --branch aBranch -- <submodule_path>)
Observe que se você possui um submódulo existente que ainda não está rastreando uma ramificação , então ( se você tiver o git 1.8.2+ ):
Verifique se o repositório pai sabe que seu submódulo agora rastreia uma ramificação:
cd /path/to/your/parent/repo
git config -f .gitmodules submodule.<path>.branch <branch>
Verifique se o seu submódulo é realmente o mais tardar nesse ramo:
cd path/to/your/submodule
git checkout -b branch --track origin/branch
# if the master branch already exist:
git branch -u origin/master master
(com 'origin' sendo o nome do repositório remoto upstream do qual o submódulo foi clonado.
Uma parte git remote -vinterna desse submódulo o exibirá. Geralmente, é 'origin')
Não se esqueça de registrar o novo estado do seu submódulo no repositório pai:
cd /path/to/your/parent/repo
git add path/to/your/submodule
git commit -m "Make submodule tracking a branch"
A atualização subsequente para esse submódulo precisará usar a --remoteopção:
# update your submodule
# --remote will also fetch and ensure that
# the latest commit from the branch is used
git submodule update --remote
# to avoid fetching use
git submodule update --remote --no-fetch
Observe que, com o Git 2.10+ (terceiro trimestre de 2016), você pode usar ' .' como um nome de filial:
O nome do ramo é registrada como submodule.<name>.branchem .gitmodulespara update --remote.
Um valor especial de .é usado para indicar que o nome da ramificação no submódulo deve ser o mesmo nome que a ramificação atual no repositório atual .
Mas, como comentado por LubosD
Com git checkout, se o nome do ramo a seguir for " .", ele matará seu trabalho não confirmado!
Use em git switchvez disso.
Isso significa Git 2.23 (agosto de 2019) ou mais.
Consulte " Confundido porgit checkout "
Se você deseja atualizar todos os seus submódulos seguindo uma ramificação:
git submodule update --recursive --remote
Observe que o resultado, para cada submódulo atualizado, quase sempre será um HEAD desanexado , como Dan Cameron observou em sua resposta .
( Clintm observa nos comentários que, se você executar git submodule update --remotee o sha1 resultante for o mesmo que o ramo em que o submódulo está atualmente, ele não fará nada e deixará o submódulo ainda "nesse ramo" e não no estado principal desanexado. )
Para garantir que o ramo seja realmente retirado (e que não modifique o SHA1 da entrada especial que representa o submódulo do repositório pai), ele sugere:
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; git switch $branch'
Cada submódulo ainda fará referência ao mesmo SHA1, mas se você fizer novos commit, poderá empurrá-los porque eles serão referenciados pela ramificação que você deseja que o submódulo rastreie.
Após esse envio dentro de um submódulo, não se esqueça de voltar ao repositório pai, adicionar, confirmar e enviar o novo SHA1 para esses submódulos modificados.
Observe o uso de $toplevel, recomendado nos comentários de Alexander Pogrebnyak .
$toplevelfoi introduzido no git1.7.2 em maio de 2010: commit f030c96 .
ele contém o caminho absoluto do diretório de nível superior (onde .gitmodulesestá).
dtmlandadiciona nos comentários :
O script foreach falhará ao fazer o check-out de submódulos que não seguem uma ramificação.
No entanto, este comando fornece os dois:
git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; [ "$branch" = "" ] && git checkout master || git switch $branch' –
O mesmo comando, mas mais fácil de ler:
git submodule foreach -q --recursive \
'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; \
[ "$branch" = "" ] && \
git checkout master || git switch $branch' –
umläute refina o comando do dtmland com uma versão simplificada nos comentários :
git submodule foreach -q --recursive 'git switch $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
várias linhas:
git submodule foreach -q --recursive \
'git switch \
$(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
Antes do Git 2.26 (primeiro trimestre de 2020), uma busca orientada a buscar atualizações recursivamente nos submódulos inevitavelmente produz resmas de saída, e fica difícil identificar mensagens de erro.
O comando foi ensinado a enumerar submódulos que apresentavam erros no final da operação .
Veja commit 0222540 (16 de janeiro de 2020) por Emily Shaffer ( nasamuffin) .
(Incorporado por Junio C Hamano - gitster- in commit b5c71cc , 5 de fevereiro de 2020)
fetch: enfatizar a falha durante a busca do submódulo
Assinado por: Emily Shaffer
Nos casos em que uma busca de submódulo falha quando há muitos submódulos, o erro da busca de submódulo com falha única é ocultado sob atividade nos outros submódulos se mais de uma busca for ativada novamente fetch-by-oid.
Chame uma falha tarde para que o usuário saiba que algo deu errado e onde .
Porque fetch_finish()só é chamado de forma síncrona por run_processes_parallel,mutexing não é necessário submodules_with_errors.