Diese GitPro-Seite fasst die Konsequenzen eines Git-Submodul-Updates gut zusammen
Wenn Sie ausführen git submodule update, wird die spezifische Version des Projekts ausgecheckt, jedoch nicht innerhalb eines Zweigs. Dies wird als abgetrennter Kopf bezeichnet. Dies bedeutet, dass die HEAD-Datei direkt auf ein Commit und nicht auf eine symbolische Referenz verweist.
Das Problem ist, dass Sie im Allgemeinen nicht in einer Umgebung mit getrenntem Kopf arbeiten möchten, da Änderungen leicht verloren gehen können .
Wenn Sie ein erstes Submodul-Update durchführen, ein Commit in diesem Submodul-Verzeichnis durchführen, ohne einen Zweig zu erstellen, in dem gearbeitet werden soll, und dann das Git-Submodul-Update erneut aus dem Superprojekt ausführen, ohne in der Zwischenzeit ein Commit durchzuführen, überschreibt Git Ihre Änderungen, ohne es Ihnen mitzuteilen. Technisch gesehen werden Sie die Arbeit nicht verlieren, aber Sie werden keinen Zweig haben, der darauf zeigt, so dass es etwas schwierig sein wird, sie abzurufen.
Anmerkung März 2013:
Wie unter " Neueste Verfolgung des Git-Submoduls " erwähnt, kann ein Submodul jetzt (git1.8.2) einen Zweig verfolgen.
# add submodule to track master branch
git submodule add -b master [URL to Git repo];
# update your submodule
git submodule update --remote
# or (with rebase)
git submodule update --rebase --remote
Siehe " git submodule update --remotevsgit pull ".
Die Antwort von MindTooth zeigt ein manuelles Update (ohne lokale Konfiguration):
git submodule -q foreach git pull -q origin master
In beiden Fällen werden dadurch die Submodulreferenzen (der Gitlink , ein spezieller Eintrag im übergeordneten Repo-Index ) geändert , und Sie müssen diese Referenzen aus dem Haupt-Repo hinzufügen, festschreiben und verschieben.
Wenn Sie das nächste Mal dieses übergeordnete Repo klonen, werden die Submodule gefüllt, um diese neuen SHA1-Referenzen wiederzugeben.
Der Rest dieser Antwort beschreibt die klassische Submodul-Funktion (Verweis auf ein festes Commit, das der springende Punkt hinter dem Begriff eines Submoduls ist).
Um dieses Problem zu vermeiden, erstellen Sie einen Zweig, wenn Sie in einem Submodulverzeichnis mit git checkout -b work oder etwas Ähnlichem arbeiten. Wenn Sie das Submodul-Update ein zweites Mal durchführen, wird Ihre Arbeit immer noch zurückgesetzt, aber Sie haben zumindest einen Zeiger, zu dem Sie zurückkehren können.
Das Wechseln von Zweigen mit Submodulen kann ebenfalls schwierig sein. Wenn Sie einen neuen Zweig erstellen, dort ein Submodul hinzufügen und dann zu einem Zweig ohne dieses Submodul zurückkehren, haben Sie das Submodulverzeichnis weiterhin als nicht verfolgtes Verzeichnis:
Um Ihre Fragen zu beantworten:
Kann ich Zweige / Modifikationen erstellen und Push / Pull wie in normalen Repos verwenden, oder gibt es Dinge, bei denen ich vorsichtig sein muss?
Sie können einen Zweig erstellen und Änderungen vornehmen.
WARNUNG (aus dem Git-Submodul-Tutorial ): Veröffentlichen (pushen) Sie immer die Submoduländerung, bevor Sie die Änderung in dem Superprojekt veröffentlichen (pushen), das darauf verweist. Wenn Sie vergessen, die Änderung des Submoduls zu veröffentlichen, können andere das Repository nicht klonen.
Wie würde ich das Submodul-referenzierte Commit von beispielsweise (markiert) 1.0 auf 1.1 vorrücken (obwohl der Kopf des ursprünglichen Repos bereits bei 2.0 liegt)?
Die Seite " Grundmodule verstehen " kann helfen
Git-Submodule werden mit zwei beweglichen Teilen implementiert:
- die
.gitmodulesDatei und
- eine besondere Art von Baumobjekt.
Diese zusammen triangulieren eine bestimmte Revision eines bestimmten Repositorys, die an einem bestimmten Ort in Ihrem Projekt ausgecheckt wird.
Von der Git-Submodul-Seite
Sie können den Inhalt des Submoduls nicht im Hauptprojekt ändern
100% korrekt: Sie können ein Submodul nicht ändern, sondern nur auf einen seiner Commits verweisen.
Wenn Sie ein Submodul innerhalb des Hauptprojekts ändern, haben Sie folgende Gründe:
- müssen innerhalb des Submoduls (zum Upstream-Modul) festschreiben und pushen , und
- Gehen Sie dann in Ihrem Hauptprojekt nach oben und schreiben Sie es erneut fest (damit sich das Hauptprojekt auf das neue Submodul-Commit bezieht, das Sie gerade erstellt und gepusht haben).
Ein Submodul ermöglicht Ihnen eine komponentenbasierte Ansatzentwicklung , bei der sich das Hauptprojekt nur auf bestimmte Commits anderer Komponenten bezieht (hier "andere Git-Repositorys, die als Submodule deklariert sind").
Ein Submodul ist ein Marker (Commit) für ein anderes Git-Repository, das nicht an den Hauptprojektentwicklungszyklus gebunden ist: Es (das "andere" Git-Repo) kann sich unabhängig voneinander entwickeln.
Es ist Sache des Hauptprojekts, aus dem anderen Repo das Commit auszuwählen, das es benötigt.
Allerdings sollten Sie wollen, aus Bequemlichkeit , modifizieren eines dieses Submodule direkt von Ihrem Hauptprojekt ermöglicht Git Sie das zu tun, vorausgesetzt , Sie zuerst diese Submodul Änderungen an den ursprünglichen Git Repo veröffentlichen und dann Hauptprojekt übertragen beziehen zu eine neue Version des Submoduls.
Die Hauptidee bleibt jedoch: Verweisen auf bestimmte Komponenten, die:
- haben ihren eigenen Lebenszyklus
- haben ihre eigenen Tags
- haben ihre eigene Entwicklung
Die Liste der spezifischen Commits, auf die Sie sich in Ihrem Hauptprojekt beziehen, definiert Ihre Konfiguration ( darum geht es bei Configuration Management, nur um das Versionskontrollsystem ).
Wenn eine Komponente wirklich zur gleichen Zeit wie Ihr Hauptprojekt entwickelt werden könnte (da jede Änderung am Hauptprojekt das Ändern des Unterverzeichnisses beinhalten würde und umgekehrt), wäre es kein "Submodul" mehr, sondern ein Teilbaumzusammenführung (auch in der Frage Übertragen der Legacy-Codebasis von Lebensläufen in ein verteiltes Repository dargestellt ), die den Verlauf der beiden Git-Repos miteinander verknüpft.
Hilft das, die wahre Natur von Git-Submodulen zu verstehen?