Submodules im Git verstehen und arbeiten

moderne Softwareprojekte stützen sich hauptsächlich auf die Arbeitsergebnisse anderer Projekte. Wenn jemand anderes hervorragende Lösungen geschrieben hat und Sie das Rad in Ihrem Code neu erfinden, wäre dies eine enorme Zeitverschwendung. Aus diesem Grund verwenden viele Projekte Code von Drittanbietern wie Bibliotheken oder Modulen.

Git, das beliebteste Versionskontrollsystem der Welt, bietet eine elegante und leistungsstarke Möglichkeit, diese Abhängigkeiten zu verwalten. Das Konzept von "Submodules" ermöglicht es uns, Drittbibliotheken einzubeziehen und zu verwalten und gleichzeitig sie von unserem eigenen Code eindeutig getrennt zu halten.

In diesem Artikel wird erklärt, warum Git -Submodule so nützlich sind, was genau sie sind und wie sie funktionieren.

Schlüsselpunkte

• Git-Submodule sind eine leistungsstarke und unkomplizierte Möglichkeit, Bibliotheken von Drittanbietern in einem Projekt zu verwalten und sie klar von der Hauptcode-Basis zu isolieren. Es handelt sich um Standard -Git -Repositories, die in einem anderen übergeordneten Git -Repository platziert sind.
• Hinzufügen von Submodule zu einem Projekt beinhaltet das Erstellen eines separaten Ordners und die Verwendung des Befehl "Git submodule add", gefolgt von der URL der gewünschten Bibliothek. Dadurch wird das Repository als Submodul in das Projekt eingerichtet und es vom Repository des Hauptprojekts getrennt.
• Beim Klonen eines Projekts mit einem Git-Submodul wird das Submodul automatisch initialisiert und unter Verwendung der Option "-Recurse-Submodules" im Befehl "Git Clone" kloniert. Wenn Sie dies nicht tun, ist der Submodule -Ordner nach dem Klonen leer und muss mit "GIT -Submodul -Update -Init -Recursive" besiedelt werden.
• Im Git -Submodul wird eine bestimmte Version ausgecheckt, keine Zweigstelle, die die vollständige Kontrolle darüber ermöglicht, welcher genaue Code im Hauptprojekt verwendet wird. Bei der Aktualisierung eines Submoduls werden "Git -Submodul -Update" verwendet, gefolgt vom Namen des Submoduls.

Halten Sie die Code -Trennung

, um klar zu veranschaulichen, warum Git -Submodule eine wertvolle Struktur sind, schauen wir uns einen Fall an, in dem keine -Submodule hat. Wenn Sie Code von Drittanbietern wie Open-Source-Bibliotheken einschließen müssen, können Sie einen einfachen Weg auswählen: Laden Sie den Code einfach von Github herunter und legen Sie ihn irgendwo in Ihr Projekt ein. Obwohl diese Methode sehr schnell ist, ist sie aus mehreren Gründen definitiv nicht sauber: Wenn Sie den Code von Drittanbietern gewaltsam in Ihr Projekt kopieren, mischen Sie tatsächlich mehrere Projekte in ein Projekt. Die Grenze zwischen Ihrem eigenen Projekt und den Projekten anderer (Bibliothek) beginnt zu verschwimmen.

Wenn Sie den Bibliothekscode aktualisieren müssen (da sein Betreuer eine großartige neue Funktion bietet oder einen ernsthaften Fehler behebt), müssen Sie erneut herunterladen, kopieren und einfügen. Dies wird bald ein mühsamer Prozess.

Die allgemeine Regel, verschiedene Dinge in der Softwareentwicklung zu trennen, ist nicht unangemessen. Dies gilt insbesondere für die Verwaltung von Code von Drittanbietern in Ihren eigenen Projekten. Glücklicherweise ist das Submodul -Konzept von Git für diese Situationen entwickelt.

• Natürlich sind Submodule nicht die einzige Lösung für solche Probleme. Sie können auch eine Vielzahl von "Packungsmanager" -Systemen verwenden, die von vielen modernen Sprachen und Frameworks bereitgestellt werden. Es ist nichts falsch daran, das zu tun!

  Sie können sich jedoch die Submodul -Architektur von Git mit einigen Vorteilen vorstellen:

  • Submodule liefern konsistente und zuverlässige Schnittstellen - unabhängig von der Sprache oder dem von Ihnen verwendeten Rahmen. Wenn Sie mehrere Technologien verwenden, kann jeder einen eigenen Paketmanager und seinen eigenen Satz von Regeln und Befehlen haben. Andererseits funktionieren Submodule immer genauso.
  • Wahrscheinlich ist nicht jeder Code über den Paketmanager verfügbar. Vielleicht möchten Sie nur Ihren eigenen Code zwischen zwei Projekten teilen - in diesem Fall kann das Submodul den einfachsten Prozess bieten.

  Die Essenz des Git -Submoduls

  Submodule in Git sind eigentlich nur Standard -Git -Repositories. Es gibt keine ausgefallene Innovation, genau das gleiche Git -Repository, mit dem wir alle sehr vertraut sind. Dies ist auch Teil der Kraft der Submodules: Sie sind so mächtig und direkt, weil sie aus technischer Sicht so "trocken" und gut getestet sind.

  Das einzige, was ein Git -Repository zu einem untergeordneten Modul macht, ist, dass es sich in einem anderen übergeordneten Git -Repository befindet.

  Abgesehen davon ist das Git -Submodul immer noch ein voll funktionsfähiges Repository: Sie können alles tun, was Sie bereits aus "normaler" Git -Arbeit kennen - vom Ändern von Dateien zum Festlegen, Ziehen und Drücken. Alles im Submodul ist möglich.

  Submodul hinzufügen

  Nehmen wir als Beispiel ein klassisches Beispiel. Angenommen, wir möchten dem Projekt eine Bibliothek von Drittanbietern hinzufügen. Es ist sinnvoll, einen separaten Ordner zu erstellen, um solche Inhalte zu speichern, bevor wir einen Code erhalten:

  $ mkdir lib
  $ cd lib

  Jetzt sind wir bereit, einen Code von Drittanbietern in unser Projekt zu importieren, indem wir Submodules ordnungsgemäß verwenden. Angenommen, wir brauchen eine kleine "Zeitzonenkonverter" JavaScript -Bibliothek:

  $ git submodule add https://github.com/spencermountain/spacetime.git

  Wenn wir diesen Befehl ausführen, kloniert Git das Repository in unser Projekt als Submodul:

  <code>Cloning into 'carparts-website/lib/spacetime'...
  remote: Enumerating objects: 7768, done.
  remote: Counting objects: 100% (1066/1066), done.
  remote: Compressing objects: 100% (445/445), done.
  remote: Total 7768 (delta 615), reused 975 (delta 588), pack-reused 6702
  Receiving objects: 100% (7768/7768), 4.02 MiB | 7.78 MiB/s, done.
  Resolving deltas: 100% (5159/5159), done.</code>

  Wenn wir uns unseren Working Copy -Ordner ansehen, können wir feststellen, dass die Bibliotheksdatei tatsächlich in unserem Projekt angekommen ist.

  

  Sie könnten fragen: "Was ist der Unterschied?" Der Hauptunterschied besteht darin, dass sie in ihrem eigenen Git -Repository

  enthalten sind! Wenn wir nur einige Dateien herunterladen, sie in unser Projekt stürzen und sie - wie die anderen Projekte - - sie werden sie zum gleichen Git -Repository begehen. Das Submodul stellt jedoch sicher, dass die Bibliotheksdateien nicht in das Repository unseres Hauptprojekts "eingetragen" werden. Mal sehen, was noch los ist: Eine neue .gitmodules -Datei wurde im Hauptprojektroot -Ordner erstellt. Das Folgende ist sein Inhalt:

  $ mkdir lib
  $ cd lib

  Diese .gitmodules -Datei ist einer von mehreren Standorten für Submodule in Git -Tracking -Projekten. Der andere ist .git/config, das jetzt wie folgt endet:

  $ git submodule add https://github.com/spencermountain/spacetime.git

  Schließlich führt Git auch eine Kopie des .git -Repositorys jedes Submoduls im internen .git/modules -Ordner.

  All dies sind technische Details, an die Sie sich nicht erinnern müssen. Es kann jedoch hilfreich sein zu verstehen, dass die interne Wartung von Git -Submodules recht komplex ist. Deshalb ist es wichtig, sich zu erinnern: Ändern Sie die GIT -Submodul -Konfiguration nicht manuell! Wenn Sie Submodules bewegen, löschen oder auf andere Weise bedienen möchten, tun Sie sich selbst einen Gefallen, versuchen Sie dies nicht manuell. Sie können die entsprechenden GIT -Befehle oder eine Git -Desktop -GUI wie "Tower" verwenden und diese Details für Sie behandeln.

  Sehen wir uns den Status des Hauptprojekts an, nachdem wir Submodules hinzugefügt haben:

  Wie Sie sehen können, behandelt Git Submodule wie andere Änderungen. Also müssen wir diese Änderung wie jede andere Änderung begehen:

  <code>Cloning into 'carparts-website/lib/spacetime'...
  remote: Enumerating objects: 7768, done.
  remote: Counting objects: 100% (1066/1066), done.
  remote: Compressing objects: 100% (445/445), done.
  remote: Total 7768 (delta 615), reused 975 (delta 588), pack-reused 6702
  Receiving objects: 100% (7768/7768), 4.02 MiB | 7.78 MiB/s, done.
  Resolving deltas: 100% (5159/5159), done.</code>

  <code>[submodule "lib/spacetime"]
    path = lib/spacetime
    url = https://github.com/spencermountain/spacetime.git</code>

  Klon Das Projekt, das das Git -Submodul enthält

  In unserem obigen Beispiel haben wir dem vorhandenen Git -Repository ein neues Submodul hinzugefügt. Aber "wiederum", was passiert, wenn Sie ein Repository klonen, das bereits das

  -Submodul enthält?

  Wenn wir einen normalen Git -Klon & lt; Remote -URL & GT; Dies beweist erneut lebhaft, dass die Submodul -Dateien unabhängig sind und nicht in ihrem übergeordneten Repository enthalten sind.

  In diesem Fall können Sie einfach das Git -Submodul -Update - -init -recursive durchführen. Eine bessere Möglichkeit besteht darin, die Option-Recurse-Submodules-Option direkt hinzuzufügen, wenn der erste Git-Klon aufgerufen wird.

  Kasseversion

  In "normalen" Git -Repositories überprüfen wir normalerweise Zweige. Durch die Verwendung von Git Checkout & lt; Branchname & gt; oder einen aktualisierten Git -Switch & lt; Branchname & GT; Wenn ein neues Komitee in dieser Filiale vorgenommen wird, verschiebt sich der Kopfzeiger automatisch

  auf das neueste Commit. Es ist wichtig, dies zu verstehen - denn Git -Submodules funktionieren anders! In Submodules schauen wir uns immer eine bestimmte Version an - keine Zweigstelle! Auch wenn Sie in einem Submodul ähnlich wie bei Git Checkout Main Befehle ausführen, ist im Hintergrund der aktuelle neueste

  Commit

  in diesem Zweig protokolliert - nicht der Zweig selbst. Natürlich ist dieses Verhalten kein Fehler. Bedenken Sie Folgendes: Wenn Sie Bibliotheken von Drittanbietern einfügen, möchten Sie die volle Kontrolle darüber, welchen genauen Code Sie in Ihrem Hauptprojekt verwenden. Dies ist großartig, wenn der Betreuer der Bibliothek eine neue Version veröffentlicht ... aber Sie möchten diese neue Version nicht unbedingt automatisch in Ihrem Projekt verwenden. Weil Sie nicht wissen, ob diese neuen Änderungen Ihr

  -Projekt brechen!

  Wenn Sie herausfinden möchten, welche Version Ihr Submodule verwendet, können Sie diese Informationen im Hauptprojekt anfordern:

  $ mkdir lib
  $ cd lib

  Dadurch wird die derzeit von unserem Lib/Spacetime -Submodul ausgecheckte Version zurückgegeben. Außerdem werden wir wissen, dass diese Version ein Tag namens "6.16.3" ist. Es ist üblich, Tags bei der Verwendung von Git -Submodule stark zu verwenden.

  Angenommen, Sie möchten, dass Ihr Submodul eine ältere Version von mit "6.14.0" benutzt. Zunächst müssen wir das Verzeichnis ändern, damit unsere Git -Befehle im Kontext des Submoduls und nicht unseres Hauptprojekts ausgeführt werden. Dann können wir einfach die Git -Checkout mit dem Tag -Namen ausführen:

  $ git submodule add https://github.com/spencermountain/spacetime.git

  Wenn wir jetzt zu unserem Hauptprojekt zurückkehren und den Git -Submodul -Status erneut ausführen, werden wir unsere Kasse sehen:

  <code>Cloning into 'carparts-website/lib/spacetime'...
  remote: Enumerating objects: 7768, done.
  remote: Counting objects: 100% (1066/1066), done.
  remote: Compressing objects: 100% (445/445), done.
  remote: Total 7768 (delta 615), reused 975 (delta 588), pack-reused 6702
  Receiving objects: 100% (7768/7768), 4.02 MiB | 7.78 MiB/s, done.
  Resolving deltas: 100% (5159/5159), done.</code>

  Sehen Sie sich die Ausgabe an: Das Symbol vor dem SHA-1-Hash zeigt uns, dass sich die Version des Submoduls von der derzeit im übergeerkten Repository gespeicherten Version unterscheidet. Da wir gerade die geprüfte Version geändert haben, sieht dies richtig aus.
  GIT -Status in unserem Hauptprojekt nun auch über diese Tatsache informiert:

  <code>[submodule "lib/spacetime"]
    path = lib/spacetime
    url = https://github.com/spencermountain/spacetime.git</code>

  Sie können sehen, dass Git bewegende Submodul -Zeiger als die gleichen Änderungen wie andere Änderungen behandelt: Wenn wir sie speichern möchten, müssen wir es für das Repository verpflichten:

  <code>[submodule "lib/spacetime"]
    url = https://github.com/spencermountain/spacetime.git
    active = true</code>

  Git Submodule aktualisieren

  In den obigen Schritten haben wir uns

  den Submodul -Zeiger verschoben: Wir sind diejenigen, die sich für verschiedene Versionen ansehen, ihn einreichen und ihn in das Remote -Repository unseres Teams weitergeben. Aber was ist, wenn unser Kollege die Submodule -Version verändert hat - vielleicht weil eine interessante neue Version des Submodule veröffentlicht wurde und unser Kollege sie in unserem Projekt verwendet hat (natürlich nach gründlicher Tests ...).

  Lassen Sie uns ein einfaches Git -Anziehen des Hauptprojekts ausführen - weil wir es möglicherweise oft tun - um neue Änderungen aus einem gemeinsam genutzten Remote -Repository zu erhalten:

  $ git status
  On branch master
  Changes to be committed:
    (use "git restore --staged <file>..." to unstage)
    new file:   .gitmodules
    new file:   lib/spacetime

  Die vorletzte Linie zeigt an, dass etwas im Submodul geändert wurde. Aber schauen wir uns genauer an:

  $ git commit -m "Add timezone converter library as a submodule"

  Ich glaube, Sie erinnern sich noch an diese kleine Zahl: Dies bedeutet, dass sich der Submodul -Zeiger bewegt hat! Um unsere lokale Checkout -Version auf die von unseren Teamkollegen ausgewählte "offizielle" Version zu aktualisieren, können wir den Befehl Update ausführen:

  $ git submodule status
     ea703a7d557efd90ccae894db96368d750be93b6 lib/spacetime (6.16.3)

  Okay! Unsere Submodules werden jetzt auf die Version in unserem Hauptprojekt -Repository untersucht!

  Verwenden von Git -Submodul

  Wir haben die grundlegenden Bausteine ​​unter Verwendung von Git -Submodules abgedeckt. Andere Workflows sind sehr Standard!
  Zum Beispiel ist die Überprüfung nach neuen Änderungen in Submodules wie in jedem anderen Git -Repository: Sie führen den Befehl git fetch im submodule repository aus. Wenn Sie Updates verwenden möchten, führen Sie möglicherweise so etwas wie Git Pull Origin Danach Main aus. Befehl.
  Das Ändern von Submodule funktioniert möglicherweise auch für Sie, insbesondere wenn Sie den Bibliothekscode selbst verwalten (da es sich um eine interne Bibliothek handelt, nicht von Dritten). Sie können Submodules wie bei jedem anderen Git -Repository verwenden: Sie können Änderungen vornehmen, sie begehen, schieben und vieles mehr.

  Holen Sie sich die Kraft von Git

  Git hat leistungsstarke Funktionen hinter den Kulissen. Viele fortschrittliche Tools wie Git -Submodules sind jedoch nicht bekannt. Viele Entwickler haben viele kraftvolle Features verpasst, was wirklich schade ist!

  Wenn Sie tiefer in einige andere fortschrittliche Git-Technologien eintauchen möchten, empfehle ich das "Advanced Git Toolkit": Dies ist eine (kostenlose!) Kurzvideosammlung, die Sie zum Reflog, interaktive Rebase, Kirschthemen wie vorstellt, Strategien auswählen und sogar Verzweigungen.

  Ich wünsche Ihnen einen besseren Entwickler!

  Häufig gestellte Fragen zu Git -Submodulen

  Was ist ein Git -Submodul? Git -Submodule ist eine Möglichkeit, ein anderes Git -Repository als Unterverzeichnis in Ihr eigenes Git -Repository aufzunehmen. Sie können ein separates Repository als Unterprojekt im Hauptprojekt beibehalten.

  Warum Git Submodul verwenden? Git -Submodule sind nützlich, um externe Repositorys in Ihr Projekt zusammenzuführen, insbesondere wenn Sie ihre Entwicklungsgeschichte vom Hauptprojekt trennen möchten. Dies ist sehr vorteilhaft, um Abhängigkeiten zu verwalten oder externe Bibliotheken einzubeziehen.

  Welche Informationen werden im Hauptprojekt über das Submodul gespeichert? Das Hauptprojekt speichert die URL und begehen Hash des Submoduls in einem speziellen Eintrag in das übergeordnete Repository. Dies ermöglicht es jedem, das Hauptprojekt zu klonieren, um auch die referenzierten Submodule zu klonen.

  Wie klonen Sie ein Git -Repository, das Submodule enthält? Beim Klonen eines Repositorys mit Submodule können Sie automatisch Submodules mit dem rekursiven Flag des Befehls git klon initialisieren und klonen. Alternativ können Sie das Git -Submodule -Update -Init nach dem Klonen verwenden.

  Kann ich Submodulen nisten? Ja, Git unterstützt verschachtelte Submodulen, was bedeutet, dass Submodules eigene Submodule enthalten kann. Das Management von verschachtelten Submodulen kann jedoch kompliziert werden, und Sie müssen sicherstellen, dass jedes Submodul ordnungsgemäß initialisiert und aktualisiert wird.

Das obige ist der detaillierte Inhalt vonSubmodules im Git verstehen und arbeiten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!