Wie kann ich meine Änderungen auf ein Git-Submodul zurücksetzen?

Ich habe ein Git-Submodul (RestKit), das ich meinem Repo hinzugefügt habe.

Ich habe dort versehentlich einige Dateien geändert und möchte zur Quellversion zurückkehren. Um das zu tun, habe ich versucht zu rennen

Mac:app-ios user$ git submodule update RestKit

Aber wie Sie hier sehen können, hat dies nicht funktioniert, da es sich immer noch um "modifizierten Inhalt" handelt:

Mac:app-ios user$ git status
...
#   modified:   RestKit (modified content)

Sogar

Mac:app-ios user$ git submodule update -f RestKit 

setzt lokal geänderte Dateien nicht zurück.
Wie setze ich den Inhalt dieses Submoduls zurück?

Wechseln Sie in das Verzeichnis des Submoduls und führen Sie dann a aus git reset --hard, um alle geänderten Dateien auf ihren letzten festgeschriebenen Status zurückzusetzen. Beachten Sie, dass dadurch alle nicht festgeschriebenen Änderungen verworfen werden.

Wenn Sie dies für alle Submodule tun möchten, ohne die Verzeichnisse ändern zu müssen, können Sie dies ausführen

git submodule foreach git reset --hard

Sie können das rekursive Flag auch verwenden, um es auf alle Submodule anzuwenden:

git submodule foreach --recursive git reset --hard

Eine ausfallsichere Methode als alle vorherigen Antworten:

git submodule deinit -f .
git submodule update --init

Der erste Befehl "löst" alle Submodule vollständig, der zweite führt dann eine neue Überprüfung durch.
Es dauert länger als die anderen Methoden, funktioniert jedoch unabhängig vom Status Ihrer Submodule.

Gut für mich zu haben

git reset --hard

Setzen Sie das Submodul einfach auf den Status zurück, in dem es ausgecheckt wurde. Dies ist für das Repo-referenzierte Commit / den Status des Main nicht erforderlich. Ich werde immer noch "geänderte Inhalte" haben, wie OP sagte. Um das Submodul wieder auf das korrekte Commit zu bringen, führe ich Folgendes aus:

git submodule update --init

Wenn ich das tue git status, ist es auf dem Submodul sauber.

Führen Sie 4 Schritte nacheinander aus:

git submodule foreach git reset --hard HEAD
git submodule update
git submodule foreach "git checkout master; git pull"
git submodule foreach git clean -f

Dies hat bei mir funktioniert, auch rekursiv in Submodule (vielleicht hat Ihr -f deshalb nicht funktioniert, weil Sie ein Submodul innerhalb des Submoduls geändert haben):

git submodule update -f --recursive

Versuchen Sie dies zuerst, wie andere gesagt haben:

git submodule update --init

Wenn dies nicht funktioniert, wechseln Sie in das Submodulverzeichnis und verwenden Sie den folgenden Befehl, um festzustellen, ob Änderungen am Submodul vorgenommen wurden:

git status

Wenn sich Änderungen an Ihrem Submodul ergeben, entfernen Sie diese. Stellen Sie sicher, dass Sie keine Änderungen sehen können, wenn Sie "git status" ausführen.

Kehren Sie als Nächstes zum Haupt-Repository zurück und führen Sie "git submodule update --init" erneut aus.

Seit Git 2.14 (Q3 2017) müssen Sie nicht mehr in jedes Submodul gehen, um ein git reset(wie in git submodule foreach git reset --hard) zu erstellen.

Das liegt daran, dass Git Reset selbst jetzt weiß, wie man rekursiv in Submodule geht.

Siehe Commit 35b96d1 (21. April 2017) und Commit f2d4899 , Commit 823bab0 , Commit cd279e2 (18. April 2017) von Stefan Beller ( stefanbeller) .
^{(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit 5f074ca , 29. Mai 2017)}

eingebaut / zurückgesetzt: Schalter --recurse-submodules hinzufügen

git-reset ist ein weiterer funktionierender Baummanipulator, der über Submodule unterrichtet werden sollte.

Wenn ein Benutzer git-reset verwendet und die Rekursion in Submodule anfordert, werden die Submodule auf den im Superprojekt aufgezeichneten Objektnamen zurückgesetzt, wodurch die HEADs getrennt werden.

Warnung : der Unterschied zwischen:

• git reset --hard --recurse-submodule und
• git submodule foreach git reset --hard

Ersteres setzt auch den Haupt-Repo-Arbeitsbaum Ihres Elternteils zurück, da Letzteres nur den Arbeitsbaum der Submodule zurücksetzt.
Also mit Vorsicht verwenden.

Für git <= 2.13 sollten diese beiden Befehle zusammen Ihre Repos mit rekursiven Submodulen zurücksetzen:

git submodule foreach --recursive git reset --hard
git submodule update --recursive --init

Dies funktioniert mit unseren Bibliotheken unter GIT v1.7.1, in denen wir ein DEV-Paket-Repo und ein LIVE-Paket-Repo haben. Die Repositorys selbst sind nichts anderes als eine Shell zum Packen der Assets für ein Projekt. alle Submodule.

Das LIVE wird niemals absichtlich aktualisiert, es können jedoch Cache-Dateien oder Unfälle auftreten, die das Repo verschmutzen. Neue Submodule, die dem DEV hinzugefügt wurden, müssen ebenfalls in LIVE initialisiert werden.

Paket-Repository in DEV

Hier möchten wir alle Upstream-Änderungen abrufen, die uns noch nicht bekannt sind, und dann unser Paket-Repository aktualisieren.

# Recursively reset to the last HEAD
git submodule foreach --recursive git reset --hard

# Recursively cleanup all files and directories
git submodule foreach --recursive git clean -fd

# Recursively pull the upstream master
git submodule foreach --recursive git pull origin master

# Add / Commit / Push all updates to the package repo
git add .
git commit -m "Updates submodules"
git push   

Paket-Repository in LIVE

Hier möchten wir die Änderungen abrufen, die in das DEV-Repository übernommen wurden, aber keine unbekannten Upstream-Änderungen.

# Pull changes
git pull

# Pull status (this is required for the submodule update to work)
git status

# Initialize / Update 
git submodule update --init --recursive

Wenn Sie alle Änderungen im gesamten Repository zusammen mit den Untermodulen verwerfen möchten, können Sie verwenden

git restore . --recurse-submodules

Dadurch werden alle im Repository und in den Submodulen vorgenommenen Änderungen rückgängig gemacht.

meine Art, alle Submodule zurückzusetzen (OHNE ihren "Master" -Zweig zu trennen und zu behalten):

git submodule foreach 'git checkout master && git reset --hard $ sha1'