Also habe ich vor ein paar Tagen mit Git angefangen. ( Sehr spät zur Party - nicht schimpfen:) ). Wirklich anfangen, mit den grundlegenden Befehlen, Ideen und Arbeitsabläufen vertraut zu werden. Submodule bringen mich jedoch wirklich auf Trab. Ich versuche, Code zum FuelPHP GitHub beizutragen und ich könnte einige Hinweise und Tipps verwenden.
Ich führe die folgenden Befehle im Terminal aus:
%Vor%Insbesondere sind meine Fragen:
1.1/develop in einem Submodul herunter, setzt mich aber standardmäßig auf *no branch ? Kann ich dieses Verhalten ändern? 1.1/master , 1.0/develop etc ..). cat .git/config in Super-Shows: Zusammen mit allen Submodulen ...
%Vor% Das Ausführen von cat .git config im Core-Submodul zeigt Folgendes an:
Wäre es klug, diese URLs zu MY Repo auf GitHub zu ändern? Treibstoff verweigert sowieso Stöße. Wenn ich ein Submodul-Update durchführe, werden sie überschrieben?
Ich habe das auch auf Fuel's Forums gefragt, aber es ist eher eine allgemeine Frage, und es gibt sie mehr Gitters hier ... DANKE!
Ja, wie in " wahre Natur der Submodule "
Ein git-Submodul ist eine Referenz auf ein bestimmtes Commit (SHA1), keine Verzweigung. Sie befinden sich also immer in einem Trennmodus (der mit einer schreibgeschützten Verwendung kompatibel ist).
Mit anderen Worten, git submodule update prüft ein bestimmtes Commit und nicht die Spitze einer Verzweigung.
Die Datei .gitmodule enthält die Referenz Ihres Submodul-Repos. Und der spezifische SHA1 wird im Parent-Repo als spezieller Commit (Modus 160000) aufgezeichnet. Wenn Sie " git submodule add " ein neues Submodul eingeben, wird der SHA1 aufgezeichnet, bei dem dieser andere Repo derzeit ausgecheckt ist (unabhängig von seiner Verzweigung).
Wenn Sie Änderungen vornehmen möchten, müssen Sie eine Verzweigung innerhalb dieses Submodul-Repos auschecken (eine vorhandene Verzweigung oder eine neue ): In beiden Fällen werden Sie jede neue Änderung zurück in den Remote-Repo von dieser schieben Submodul).
Eine Alternative wäre git slave .
Siehe 2. Die anderen Zweigstellen, die in git branch aufgelistet sind, sind die lokalen Zweigstellen, die in Ihrem Submodul-Repo vorhanden sind, einschließlich einer lokalen Zweigstelle für jeden Tracking-Zweig , wenn Sie an einem Punkt git pull erstellt haben.
Da das übergeordnete Element immer noch auf das anfängliche SHA1 des Submoduls verweist.
Aber da Sie Änderungen daran vorgenommen haben, muss SHA1 aktualisiert werden.
Denken Sie daran, dass das Submodul ein Git Repo in sich ist ... mit absolut keiner Ahnung, dass es als Submodul verwendet wird. Daher die Notwendigkeit, den neuen Zustand dieses Repos im Parent-Repo aufzuzeichnen (der einzige, der den Zustand seiner Submodule verfolgt)
Ihr erster git-Push ist eine interne Operation des Submodul-Repos (die vom übergeordneten Repo überhaupt nicht gesehen wird).
Für ein Eltern-Repo ist das Submodul Repo eine "Black Box" mit nur einer Remote-Adresse und einem SHA1. Was auch immer innerhalb des Submoduls getan wird, hat keine Auswirkung auf den Elternteil, der nur die Änderung des SHA1 des Submodulbaums erkennt.
Die Verwendung von Gabeln könnte helfen Siehe " Remote-Repository für ein Git-Submodul ändern ", um die Remote-URL Ihres Submoduls zu aktualisieren.