BEARBEITEN:
Eine gültige Lösung finden Sie unter @ Simba- Antwort
submodule.<name>.updateist das, was Sie ändern möchten. Weitere Informationen finden Sie in den Dokumenten - Standardmäßig wirdcheckout
submodule.<name>.branch der zu verfolgende Remote-Zweig angegeben - Standardmaster
ALTE ANTWORT:
Persönlich hasse ich Antworten hier, die auf externe Links verweisen, die im Laufe der Zeit möglicherweise nicht mehr funktionieren, und überprüfe meine Antwort hier (es sei denn, die Frage ist doppelt vorhanden) - auf Fragen, die das Thema zwischen den Zeilen eines anderen Themas abdecken, aber insgesamt gleich sind: "Ich bin nicht antworten, lesen Sie die Dokumentation. "
Zurück zur Frage: Warum passiert das?
Situation, die Sie beschrieben haben
Nach dem Abrufen von Änderungen vom Server wird mein Submodulkopf häufig vom Hauptzweig getrennt.
Dies ist ein häufiger Fall, wenn man Submodule nicht zu oft verwendet oder gerade mit Submodulen begonnen hat . Ich glaube, dass ich zu Recht sage, dass wir alle irgendwann dort waren, wo sich der KOPF unseres Submoduls löst.
- Ursache: Ihr Submodul verfolgt nicht den richtigen Zweig (Standardmaster).
Lösung: Stellen Sie sicher, dass Ihr Submodul den richtigen Zweig verfolgt
$ 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>
- Ursache: Ihr übergeordnetes Repo ist nicht für die Verfolgung des Submodulzweigs konfiguriert.
Lösung: Lassen Sie Ihr Submodul seinen Remote-Zweig verfolgen, indem Sie mit den folgenden beiden Befehlen neue Submodule hinzufügen.
- Zuerst sagst du git, dass er deine Fernbedienung verfolgen soll
<branch>.
- Sie weisen git an, Rebase oder Merge anstelle von Checkout durchzuführen
- Sie weisen git an, Ihr Submodul von remote zu aktualisieren.
$ git submodule add -b <branch> <repository> [<submodule-path>]
$ git config -f .gitmodules submodule.<submodule-path>.update rebase
$ git submodule update --remote
- Wenn Sie Ihr vorhandenes Submodul nicht wie folgt hinzugefügt haben, können Sie dies leicht beheben:
- Zuerst möchten Sie sicherstellen, dass in Ihrem Submodul der Zweig ausgecheckt ist, den Sie verfolgen möchten.
$ 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>
In den meisten Fällen haben Sie Ihren DETACHED HEAD bereits behoben, da er mit einem der oben genannten Konfigurationsprobleme zusammenhängt.
Befestigen des abgenommenen Kopfes wenn .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.
Wenn Sie es jedoch geschafft haben, einige Änderungen lokal bereits für das Submodul vorzunehmen und diese festzuschreiben, haben Sie diese auf remote verschoben. Wenn Sie dann 'git checkout' ausgeführt haben, benachrichtigt Git Sie:
$ 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:
Die empfohlene Option zum Erstellen eines temporären Zweigs kann gut sein, und dann können Sie diese Zweige usw. einfach zusammenführen. Ich persönlich würde sie jedoch nur git cherry-pick <hash>in diesem Fall verwenden.
$ 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>
Obwohl es noch einige weitere Fälle gibt, in denen Sie Ihre Submodule in den Status DETACHED HEAD versetzen können, hoffe ich, dass Sie jetzt ein bisschen mehr verstehen, wie Sie Ihren speziellen Fall debuggen können.