Vorab: Ich bin git-Anfänger.
Wenn man nach einem git-Äquivalent zu svn:externals sucht, liest man von zwei Optionen:
- Subtree merges: “very easy on other users, because it is automatically included when the repository is checked out or cloned”
- Submodules: “all users have to manage the submodules, which are not automatically included in checkouts”
Die Zitate sind aus dem verlinkten Beitrag, aber die Tendenz “Submodules will man nicht” liest man auch an anderer Stelle [1, 2]. Meiner Meinung nach ist es genau andersrum:
Bei Subtree merges werden die externen Sourcen in das aktuelle Projekt gelegt – und nicht nur verlinkt! Das heißt, man pusht die (vermeintlich) externen Sourcen in das aktuelle Projekt. Ja, dadurch klont sie ab dem Moment auch jeder automatisch (vgl. Zitat oben), trotzdem entspricht das nicht dem Sinn und Zweck.
Darüber hinaus hatte ich zeitweise das Problem, dass Dateien aus dem externen Projekt gleich benamte lokale Dateien überschreiben wollten (bei README.md, composer.json, .gitignore, make, … durchaus ein Problem!). Das mag aber ein Anwenderfehler gewesen sein; nachdem mir Problem #1 klar wurde, habe ich Subtree merges nicht weiter verfolgt.
Submodules erfordern zwei zusätzliche Schritte beim Klonen (git submodule init, git submodule update), sowie einen beim Update, wenn sich das Submodule ebenfalls geändert hat (git submodule update). Dafür sind die externen Sourcen nun “nur” verlinkt, also wie bei SVN Externals. Dumm: Wenn sich das externe Projekt ändert, muss man den “Link” auf den entsprechenden neuen Hash zeigen lassen, und das auch commiten. Passt jemand nicht auf und commitet nun wieder den alten Link, revertet er dadurch die Änderung.
Das spricht aber nicht gegen Submodules als Externals-Ersatz – es spricht höchstens gegen git, wo alles “ein wenig” komplizierter ist, als es sein sollte :-/ PS dazu: Ich habe mein Glück die meiste Zeit auf der Kommandozeile versucht, erst später zeigte Tobi mir Sourcetree. Damit sollte das leichter sein.