EDITAR:
Consulte @Simba Answer para obter uma solução válida
submodule.<name>.updateé o que você deseja alterar, consulte os documentos - padrãocheckout
submodule.<name>.branch especificar ramo remoto a ser rastreado - padrãomaster
RESPOSTA ANTIGA:
Pessoalmente, eu odeio respostas aqui que direcionam para links externos que podem parar de funcionar com o tempo e verifique minha resposta aqui (a menos que a pergunta seja duplicada) - direcionando para a pergunta que cobre o assunto entre as linhas de outro assunto, mas no geral é igual a: "Estou não responder, leia a documentação ".
Então, voltando à pergunta: por que isso acontece?
Situação que você descreveu
Depois de extrair alterações do servidor, muitas vezes meu cabeçalho do submodulo é desanexado da ramificação principal.
Este é um caso comum quando não se usa submódulos com muita frequência ou apenas se inicia com submódulos . Acredito que estou correto ao afirmar que todos já estivemos lá em algum momento em que o HEAD do nosso submódulo é desanexado.
- Causa: seu submódulo não está rastreando a ramificação correta (mestre padrão).
Solução: verifique se o submódulo está rastreando a ramificação correta
$ cd <submodule-path>
# if the master branch already exists locally:
# (From git docs - branch)
# -u <upstream>
# --set-upstream-to=<upstream>
# Set up <branchname>'s tracking information so <upstream>
# is considered <branchname>'s upstream branch.
# If no <branchname> is specified, then it defaults to the current branch.
$ git branch -u <origin>/<branch> <branch>
# else:
$ git checkout -b <branch> --track <origin>/<branch>
- Causa: seu repositório pai não está configurado para rastrear ramificações de submódulos.
Solução: Faça seu submódulo rastrear sua ramificação remota adicionando novos submódulos com os dois comandos a seguir.
- Primeiro você diz ao git para rastrear seu controle remoto
<branch>.
- você diz ao git para executar uma nova alteração ou mesclagem, em vez de fazer o checkout
- você diz ao git para atualizar seu submódulo do controle remoto.
$ git submodule add -b <branch> <repository> [<submodule-path>]
$ git config -f .gitmodules submodule.<submodule-path>.update rebase
$ git submodule update --remote
- Se você não adicionou seu submódulo existente como esse, você pode facilmente corrigir isso:
- Primeiro, você quer ter certeza de que seu submódulo possui a ramificação que você deseja rastrear.
$ cd <submodule-path>
$ git checkout <branch>
$ cd <parent-repo-path>
# <submodule-path> is here path releative to parent repo root
# without starting path separator
$ git config -f .gitmodules submodule.<submodule-path>.branch <branch>
$ git config -f .gitmodules submodule.<submodule-path>.update <rebase|merge>
Nos casos mais comuns, você já corrigiu agora o seu CABEÇOTE DETALHADO, pois estava relacionado a um dos problemas de configuração acima.
fixação da CABEÇA DESTACADA quando .update = checkout
$ cd <submodule-path> # and make modification to your submodule
$ git add .
$ git commit -m"Your modification" # Let's say you forgot to push it to remote.
$ cd <parent-repo-path>
$ git status # you will get
Your branch is up-to-date with '<origin>/<branch>'.
Changes not staged for commit:
modified: path/to/submodule (new commits)
# As normally you would commit new commit hash to your parent repo
$ git add -A
$ git commit -m"Updated submodule"
$ git push <origin> <branch>.
$ git status
Your branch is up-to-date with '<origin>/<branch>'.
nothing to commit, working directory clean
# If you now update your submodule
$ git submodule update --remote
Submodule path 'path/to/submodule': checked out 'commit-hash'
$ git status # will show again that (submodule has new commits)
$ cd <submodule-path>
$ git status
HEAD detached at <hash>
# as you see you are DETACHED and you are lucky if you found out now
# since at this point you just asked git to update your submodule
# from remote master which is 1 commit behind your local branch
# since you did not push you submodule chage commit to remote.
# Here you can fix it simply by. (in submodules path)
$ git checkout <branch>
$ git push <origin>/<branch>
# which will fix the states for both submodule and parent since
# you told already parent repo which is the submodules commit hash
# to track so you don't see it anymore as untracked.
Mas se você conseguiu fazer algumas alterações localmente já para o submódulo e confirmado, envie-as para remoto, quando você executar o 'git checkout', o Git notificará você:
$ git checkout <branch>
Warning: you are leaving 1 commit behind, not connected to any of your branches:
If you want to keep it by creating a new branch, this may be a good time to do so with:
A opção recomendada para criar uma ramificação temporária pode ser boa e, em seguida, você pode mesclar essas ramificações etc. No entanto, eu pessoalmente usaria apenas git cherry-pick <hash>neste caso.
$ git cherry-pick <hash> # hash which git showed you related to DETACHED HEAD
# if you get 'error: could not apply...' run mergetool and fix conflicts
$ git mergetool
$ git status # since your modifications are staged just remove untracked junk files
$ rm -rf <untracked junk file(s)>
$ git commit # without arguments
# which should open for you commit message from DETACHED HEAD
# just save it or modify the message.
$ git push <origin> <branch>
$ cd <parent-repo-path>
$ git add -A # or just the unstaged submodule
$ git commit -m"Updated <submodule>"
$ git push <origin> <branch>
Embora existam mais casos, você pode colocar seus submódulos no estado DETACHED HEAD, espero que você entenda agora um pouco mais sobre como depurar seu caso específico.