EDYTOWAĆ:
Prawidłowe rozwiązanie znajdziesz w @Simba Answer
submodule.<name>.updateto, co chcesz zmienić, zobacz dokumentację - domyślniecheckout
submodule.<name>.branch określ zdalną gałąź do śledzenia - domyślniemaster
STARA ODPOWIEDŹ:
Osobiście nienawidzę tutaj odpowiedzi kierujących do zewnętrznych linków, które z czasem mogą przestać działać i sprawdź moją odpowiedź tutaj (chyba że pytanie jest powtórzone) - kierując do pytania, które obejmuje temat między wierszami innego tematu, ale ogólnie jest równe: „Jestem nie odpowiadając, przeczytaj dokumentację. ”
Wróćmy więc do pytania: dlaczego tak się dzieje?
Sytuacja, którą opisałeś
Po pobraniu zmian z serwera wiele razy moja głowa podmodułu jest odłączana od gałęzi głównej.
Jest to częsty przypadek, gdy nie używa się podmodułów zbyt często lub dopiero zaczynamy z modułami podrzędnymi . Uważam, że mam rację stwierdzając, że wszyscy byliśmy w pewnym momencie, w którym nastąpiło odłączenie HEAD naszego submodułu .
- Przyczyna: Twój moduł podrzędny nie śledzi prawidłowej gałęzi (domyślny master).
Rozwiązanie: upewnij się, że podmoduł śledzi prawidłową gałąź
$ 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>
- Przyczyna: Twoje nadrzędne repozytorium nie jest skonfigurowane do śledzenia gałęzi modułów podrzędnych.
Rozwiązanie: spraw, aby moduł podrzędny śledził jego gałąź zdalną, dodając nowe moduły podrzędne za pomocą następujących dwóch poleceń.
- Najpierw każesz gitowi śledzić twojego pilota
<branch>.
- mówisz gitowi, aby wykonał rebase lub merge zamiast checkout
- mówisz gitowi, aby zaktualizował twój moduł podrzędny z pilota.
$ git submodule add -b <branch> <repository> [<submodule-path>]
$ git config -f .gitmodules submodule.<submodule-path>.update rebase
$ git submodule update --remote
- Jeśli nie dodałeś swojego istniejącego modułu podrzędnego w ten sposób, możesz łatwo to naprawić:
- Najpierw chcesz się upewnić, że Twój podmoduł ma zaznaczoną gałąź, którą chcesz śledzić.
$ 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>
W typowych przypadkach już naprawiłeś ODŁĄCZONEJ GŁOWICY, ponieważ było to związane z jednym z powyższych problemów z konfiguracją.
mocowanie ODŁĄCZONEJ GŁOWY, gdy .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.
Ale jeśli udało ci się wprowadzić pewne zmiany lokalnie już dla modułu podrzędnego i zatwierdziłeś, przekazałeś je do zdalnego, a następnie po wykonaniu polecenia „git checkout”, Git powiadamia:
$ 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:
Zalecana opcja tworzenia tymczasowej gałęzi może być dobra, a następnie możesz po prostu scalić te gałęzie itp. Jednak osobiście użyłbym tylko git cherry-pick <hash>w tym przypadku.
$ 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>
Chociaż istnieje więcej przypadków, w których można wprowadzić moduły podrzędne w stan ODŁĄCZONA GŁOWA, mam nadzieję, że teraz rozumiesz nieco więcej, jak debugować konkretny przypadek.