Ich bin der Meinung, dass die Verwendung von Git-Submodulen für meinen Entwicklungsworkflow irgendwie problematisch ist. Ich habe von Git Subtree und Gitslave gehört.
Antworten:
Welches für Sie am besten geeignet ist, hängt von Ihren Bedürfnissen, Wünschen und Arbeitsabläufen ab. Sie sind in gewisser Hinsicht semi-isomorph, nur einige sind für bestimmte Aufgaben viel einfacher zu verwenden als andere.
gitslave ist nützlich, wenn Sie die Teilprojekte mehr oder weniger gleichzeitig mit dem Superprojekt steuern und entwickeln und wenn Sie normalerweise alle Repositorys gleichzeitig markieren, verzweigen, verschieben, ziehen usw. möchten. gitslave wurde noch nie an Windows getestet, von dem ich weiß. Es erfordert Perl.
git-submodule ist besser, wenn Sie die Teilprojekte nicht steuern oder das Teilprojekt genauer auf eine bestimmte Revision festlegen möchten, selbst wenn sich das Teilprojekt ändert. Git-Submodul ist ein Standardteil von Git und würde daher unter Windows funktionieren.
git-subtree bietet ein Front-End für die integrierte Zusammenführungsstrategie von git. Es ist besser, wenn Sie einen "einheitlichen" Git-Verlauf mit einem einzigen Repository bevorzugen. Im Gegensatz zur Strategie zum Zusammenführen von Teilbäumen ist es einfacher, Änderungen an den verschiedenen (Verzeichnis-) Bäumen wieder in das ursprüngliche Projekt zu exportieren, aber es ist nicht so automatisch wie bei gitslave oder sogar git-submodule.
Repo ist theoretisch ähnlich wie Gitslave, aber für nicht-androide Operationen, die ich gefunden habe, nicht so gut dokumentiert. Es ist ziemlich stark auf das Google Android-Entwicklungsmodell ausgerichtet und unterstützt nur nativ eine Handvoll Git-Befehle (obwohl Sie beliebige Befehle ausführen können). Die eingeschränkte native Unterstützung unterstützt beispielsweise kein zentrales Repository, in das Sie pushen und auschecken können Zweig scheint ziemlich schwierig.
kitenets mr ist das, was Sie verwenden möchten, wenn Sie mehrere Versionskontrollsysteme verwenden, ist jedoch aufgrund seines Ansatzes mit dem kleinsten gemeinsamen Nenner meist nur für Git-Superprojekte beschränkt. Es gibt Möglichkeiten, beliebige Befehle auszuführen, diese sind jedoch nicht so gut integriert.
mr run git config ...oder (noch schlimmer) die Konfigurationsdateimethode sprechen, um bestimmte Befehle auf Namen zu aliasen. Wenn Sie sich einer mr-Funktionalität bewusst sind, die beim Lesen der Manpage nicht sofort erkennbar war, würde ich gerne davon erfahren.
git/contrib. Installieren Sie in Ubuntu mit sudo make install install-doc prefix=/usr libexecdir=/usr/lib/git-corevon einem Git-Quellbaum (funktioniert nicht mit dem gepackten Git).
Ich verwende derzeit Submodule für die Entwicklung und nicht nur für Bibliotheken von Drittanbietern. Es gibt einige Möglichkeiten, wie Sie das Leben mit Submodulen erleichtern können, insbesondere wenn sie die Ursache für Zusammenführungs- oder Rebase-Konflikte sind. Suchen Sie in ls-tree nach den 2 Commits, die an einem Konflikt im Submodul beteiligt sind. Dies ist wahrscheinlich der schwierigste Teil von Submodulen, mit dem sich Menschen befassen müssen. Im Moment wird das Arbeiten mit Skripten viel einfacher. Zukünftige Versionen von Git sollten eine bessere native Unterstützung für den Umgang mit ihnen haben.
Hoffe das hilft.
Bei der Verwendung von Git-Submodulen in Projekten, in denen Abhängigkeiten in verschiedenen Sprachen bestehen, ist ein ähnliches Problem aufgetreten. Um mit ihnen fertig zu werden, haben wir ein Tool namens MDLR ("Modular") erstellt und als Open-Source-Tool bereitgestellt, das Ihnen deklarative versionierte Git-Abhängigkeiten mit ähnlichen Funktionen wie Git-Submodule bietet, jedoch ohne den lästigen Workflow. Sie können es installieren und Ihre Abhängigkeiten mit den Anweisungen / Downloads auf dem GitHub-Repo verwalten
Für einige Anwendungsfälle hat mir jeder der folgenden zwei einfachen Ansätze gefallen:
Verschachtelte Repositorys. Wenn Ihr Softwareprojekt über einen Plugin-Mechanismus verfügt, bei dem sich jedes Plugin in einem eigenen Unterverzeichnis befindet, kann es sinnvoll sein, diese Plugin-Verzeichnisse zu ignorieren und in Ihrem lokalen Dateisystem jedes Plugin in ein eigenes Git-Repository zu verschieben. Auf diese Weise bilden alle Ihre Dateien einen einzigen Verzeichnisbaum, werden jedoch in verschiedenen Git-Repositorys verwaltet. Es wird Git nicht verwirren.
Repositorys pro Paket. Für Softwareprojekte, bei denen Sie eine Art Quellcode-Paketverwaltungssystem verwenden (gem / bundler, npm, pear oder dergleichen), kann es sinnvoll sein, Ihren wiederverwendeten Code in separate Git-Repositorys zu stellen und dann Quellpakete daraus zu erstellen. und dann, um sie mit dem Paketverwaltungstool im übergeordneten Projekt zu installieren. Das Git-Repository Ihres übergeordneten Projekts enthält nur einen Verweis auf die erforderlichen Pakete und deren Versionen, während der tatsächliche Code dieser Pakete wie bei allen anderen Paketen und externen Bibliotheken ebenfalls ignoriert wird. Im Vergleich zu den oben vorgeschlagenen verschachtelten Repositorys ist dies ein aufwändigerer Ansatz, da hier angegeben werden kann, welche Paketversion installiert werden soll.