Fügt das angegebene Repository als Submodul am angegebenen Pfad dem zu committenden Änderungsstapel des aktuellen Projekts hinzu. Das aktuelle Projekt wird als "Superprojekt" bezeichnet.

Zeigt den Status der Submodule an. Dies gibt die SHA-1 des aktuell ausgecheckten Commits für jedes Submodul aus, zusammen mit dem Pfad des Submoduls und der Ausgabe von *git describe* für die SHA-1. Jede SHA-1 wird möglicherweise mit - präfigiert, wenn das Submodul nicht initialisiert ist, +, wenn der aktuell ausgecheckte Submodul-Commit nicht mit der in der Index des enthaltenden Repositorys gefundenen SHA-1 übereinstimmt, und U, wenn das Submodul Merge-Konflikte aufweist.

Initialisiert die im Index aufgezeichneten Submodule (die anderswo hinzugefügt und committet wurden), indem submodule.$name.url in .git/config gesetzt wird, wobei dieselbe Einstellung aus .gitmodules als Vorlage verwendet wird. Wenn die URL relativ ist, wird sie mithilfe des Standard-Remotes aufgelöst. Wenn kein Standard-Remote vorhanden ist, wird das aktuelle Repository als Upstream angenommen.

Registriert die angegebenen Submodule ab, d.h. entfernt den gesamten submodule.$name Abschnitt aus .git/config zusammen mit ihren Arbeitsbäumen. Weitere Aufrufe von git submodule update, git submodule foreach und git submodule sync werden nicht registrierte Submodule überspringen, bis sie erneut initialisiert werden. Verwenden Sie diesen Befehl, wenn Sie keine lokale Kopie des Submoduls mehr in Ihrem Arbeitsbaum haben möchten.

Legt den Standard-Remote-Tracking-Branch für das Submodul fest. Die Option --branch erlaubt die Angabe des Remote-Branches. Die Option --default entfernt den Konfigurationseintrag submodule.<name>.branch, wodurch der Tracking-Branch auf den Remote *HEAD* zurückfällt.

Setzt die URL des angegebenen Submoduls auf <newurl>. Anschließend synchronisiert es automatisch die Remote-URL-Konfiguration des Submoduls.

Zeigt die Commit-Zusammenfassung zwischen dem angegebenen Commit (standardmäßig HEAD) und dem Arbeitsbaum/Index an. Für ein betreffendes Submodul wird eine Reihe von Commits im Submodul zwischen dem angegebenen Superprojekt-Commit und dem Index oder Arbeitsbaum (umgeschaltet durch --cached) angezeigt. Wenn die Option --files angegeben ist, wird die Reihe von Commits im Submodul zwischen dem Index des Superprojekts und dem Arbeitsbaum des Submoduls angezeigt (diese Option erlaubt weder die Verwendung der Option --cached noch die Angabe eines expliziten Commits).

Evaluiert einen beliebigen Shell-Befehl in jedem ausgecheckten Submodul. Der Befehl hat Zugriff auf die Variablen $name, $sm_path, $displaypath, $sha1 und $toplevel: $name ist der Name des relevanten Submodulabschnitts in .gitmodules, $sm_path ist der Pfad des Submoduls, wie er im direkten Superprojekt aufgezeichnet wurde, $displaypath enthält den relativen Pfad vom aktuellen Arbeitsverzeichnis zum Stammverzeichnis des Submoduls, $sha1 ist der Commit, wie er im direkten Superprojekt aufgezeichnet wurde, und $toplevel ist der absolute Pfad zur obersten Ebene des direkten Superprojekts. Beachten Sie, dass zur Vermeidung von Konflikten mit *<tt>PATH* unter Windows die Variable *$path* nun ein veraltetes Synonym der Variable *<tt>$sm_path* ist. Alle im Superprojekt definierten, aber nicht ausgecheckten Submodule werden von diesem Befehl ignoriert. Sofern nicht --quiet angegeben ist, gibt foreach vor der Auswertung des Befehls den Namen jedes Submoduls aus. Wenn --recursive angegeben ist, werden Submodule rekursiv durchlaufen (d.h. der angegebene Shell-Befehl wird auch in verschachtelten Submodulen ausgewertet). Ein Rückgabewert ungleich Null des Befehls in einem beliebigen Submodul führt zum Abbruch der Verarbeitung. Dies kann durch Hinzufügen von *|| :* am Ende des Befehls überschrieben werden.

git submodule foreach 'echo $sm_path `git rev-parse HEAD`'

Synchronisiert die Remote-URL-Konfigurationseinstellungen der Submodule mit dem in .gitmodules angegebenen Wert. Es werden nur die Submodule betroffen, die bereits einen URL-Eintrag in .git/config haben (was der Fall ist, wenn sie initialisiert oder neu hinzugefügt wurden). Dies ist nützlich, wenn sich Submodul-URLs upstream ändern und Sie Ihre lokalen Repositorys entsprechend aktualisieren müssen.

Wenn sich ein Git-Verzeichnis eines Submoduls innerhalb des Submoduls befindet, wird das Git-Verzeichnis des Submoduls in den Pfad $GIT_DIR/modules des Superprojekts verschoben und dann das Git-Verzeichnis und sein Arbeitsverzeichnis verbunden, indem core.worktree gesetzt und eine .git-Datei hinzugefügt wird, die auf das im Git-Verzeichnis des Superprojekts eingebettete Git-Verzeichnis verweist.

Gibt nur Fehlermeldungen aus.

Diese Option ist nur für die Befehle add und update gültig. Der Fortschritt wird standardmäßig auf dem Standardfehlerstrom gemeldet, wenn dieser an ein Terminal angeschlossen ist, es sei denn, -q wird angegeben. Dieses Flag erzwingt die Anzeige des Fortschritts, auch wenn der Standardfehlerstrom nicht an ein Terminal umgeleitet ist.

Diese Option ist nur für den Befehl deinit gültig. Registriert alle Submodule im Arbeitsbaum ab.

Branch des Repositorys, der als Submodul hinzugefügt werden soll. Der Name des Branches wird als submodule.<name>.branch in .gitmodules für update --remote aufgezeichnet. Ein Sonderwert von . wird verwendet, um anzuzeigen, dass der Name des Branches im Submodul denselben Namen wie der aktuelle Branch im aktuellen Repository haben soll. Wenn die Option nicht angegeben ist, wird standardmäßig der Remote *HEAD* verwendet.

Diese Option ist nur für die Befehle add, deinit und update gültig. Beim Ausführen von add erlaubt das Hinzufügen eines ansonsten ignorierten Submodulpfads. Diese Option wird auch verwendet, um die Überprüfung zu umgehen, dass der Name des Submoduls nicht bereits verwendet wird. Standardmäßig schlägt *git submodule add* fehl, wenn der vorgeschlagene Name (der vom Pfad abgeleitet wird) bereits für ein anderes Submodul im Repository registriert ist. Die Verwendung von *--force* erlaubt dem Befehl, fortzufahren, indem automatisch ein eindeutiger Name durch Anhängen einer Nummer an den widersprüchlichen Namen generiert wird (z.B. wenn ein Submodul namens *child* existiert, wird *child1* usw. versucht). Beim Ausführen von deinit werden die Arbeitsbäume der Submodule auch dann entfernt, wenn sie lokale Änderungen enthalten. Beim Ausführen von update (nur wirksam mit der checkout-Prozedur) werden lokale Änderungen in Submodulen verworfen, wenn zu einem anderen Commit gewechselt wird; und es wird immer ein checkout-Vorgang im Submodul ausgeführt, auch wenn der im Index des enthaltenden Repositorys aufgeführte Commit mit dem im Submodul ausgecheckten Commit übereinstimmt.

Diese Option ist nur für die Befehle status und summary gültig. Diese Befehle verwenden typischerweise den im Submodul HEAD gefundenen Commit, aber mit dieser Option wird stattdessen der im Index gespeicherte Commit verwendet.

Diese Option ist nur für den Befehl summary gültig. Dieser Befehl vergleicht den Commit im Index mit dem im Submodul HEAD, wenn diese Option verwendet wird.

Diese Option ist nur für den Befehl summary gültig. Begrenzt die Größe der Zusammenfassung (Anzahl der angezeigten Commits insgesamt). Die Angabe von 0 deaktiviert die Zusammenfassung; eine negative Zahl bedeutet unbegrenzt (Standard). Diese Begrenzung gilt nur für geänderte Submodule. Die Größe ist immer auf 1 für hinzugefügte/gelöschte/typgewechselte Submodule begrenzt.

Diese Option ist nur für den Befehl update gültig. Anstatt die vom Superprojekt aufgezeichnete SHA-1 zur Aktualisierung des Submoduls zu verwenden, wird der Status des Remote-Tracking-Branches des Submoduls verwendet. Das verwendete Remote ist das Remote des Branches (branch.<name>.remote), standardmäßig origin. Der verwendete Remote-Branch ist standardmäßig der Remote *HEAD*, aber der Branch-Name kann durch Setzen der Option submodule.<name>.branch entweder in .gitmodules oder .git/config überschrieben werden (wobei .git/config Vorrang hat).

Diese Option ist nur für den Befehl update gültig. Holt keine neuen Objekte von der Remote-Seite.

Diese Option ist nur für den Befehl update gültig. Checkt den im Superprojekt aufgezeichneten Commit mit einem getrennten HEAD im Submodul aus. Dies ist das Standardverhalten. Der Hauptzweck dieser Option ist es, submodule.$name.update zu überschreiben, wenn dieser auf einen anderen Wert als checkout gesetzt ist. Wenn der Schlüssel submodule.$name.update entweder nicht explizit gesetzt ist oder auf checkout gesetzt ist, ist diese Option implizit.

Diese Option ist nur für den Befehl update gültig. Mergt den im Superprojekt aufgezeichneten Commit in den aktuellen Branch des Submoduls. Wenn diese Option gegeben ist, wird der HEAD des Submoduls nicht getrennt. Wenn ein Merge-Fehler diesen Prozess verhindert, müssen Sie die resultierenden Konflikte innerhalb des Submoduls mit den üblichen Werkzeugen zur Konfliktlösung beheben. Wenn der Schlüssel submodule.$name.update auf merge gesetzt ist, ist diese Option implizit.

Diese Option ist nur für den Befehl update gültig. Rebased den aktuellen Branch auf den im Superprojekt aufgezeichneten Commit. Wenn diese Option gegeben ist, wird der HEAD des Submoduls nicht getrennt. Wenn ein Merge-Fehler diesen Prozess verhindert, müssen Sie diese Fehler mit git-rebase[1] beheben. Wenn der Schlüssel submodule.$name.update auf rebase gesetzt ist, ist diese Option implizit.

Diese Option ist nur für den Befehl update gültig. Initialisiert alle Submodule, für die "git submodule init" bisher nicht aufgerufen wurde, bevor aktualisiert wird.

Diese Option ist nur für den Befehl add gültig. Sie setzt den Namen des Submoduls auf die gegebene Zeichenkette anstelle des Standardpfads. Der Name muss als Verzeichnisname gültig sein und darf nicht mit einem */* enden.

Diese Option ist nur für die Befehle add und update gültig. Diese Befehle müssen manchmal ein Remote-Repository klonen. In diesem Fall wird diese Option an den Befehl git-clone[1] weitergegeben.

Diese Option ist nur für die Befehle add und update gültig. Diese Befehle müssen manchmal ein Remote-Repository klonen. In diesem Fall wird diese Option an den Befehl git-clone[1] weitergegeben.

Diese Option ist nur für die Befehle foreach, update, status und sync gültig. Durchläuft Submodule rekursiv. Die Operation wird nicht nur in den Submodulen des aktuellen Repos ausgeführt, sondern auch in allen verschachtelten Submodulen innerhalb dieser Submodule (und so weiter).

Diese Option ist für die Befehle add und update gültig. Erstellt einen *flachen* Klon mit einer auf die angegebene Anzahl von Revisionen gekürzten Historie. Siehe git-clone[1].

Diese Option ist nur für den Befehl update gültig. Der initiale Klon eines Submoduls verwendet standardmäßig den empfohlenen Wert von submodule.<name>.shallow, wie er von der Datei .gitmodules bereitgestellt wird. Um die Vorschläge zu ignorieren, verwenden Sie --no-recommend-shallow.

Diese Option ist nur für den Befehl update gültig. Klont neue Submodule parallel mit so vielen Jobs. Standardmäßig wird die Option submodule.fetchJobs verwendet.

Diese Option ist nur für den Befehl update gültig. Klont nur einen Branch während des Updates: HEAD oder einen, der mit --branch angegeben wurde.

Pfade zu Submodul(en). Wenn angegeben, beschränkt dies den Befehl auf die Operationen nur auf den Submodulen, die an den angegebenen Pfaden gefunden wurden. (Dieses Argument ist bei add erforderlich).