Geeigneter Einsatz von git subtree/Submodul/Teilprojekt/Slave

Question

ich eine Website in Drupal entwickle, und meine Entwicklung Verzeichnisbaum ist wie folgt:

modules 
    -->moduleA 
     -->moduleA.inc 
     -->moduleA.info 
     -->moduleA.php 
    -->moduleB 
     -->moduleB.inc 
     -->moduleB.info 
     -->moduleB.php 
themes 
    -->themeA 
     -->themeA.info 
     -->page.tpl.php 
    -->themeB 
     -->themeB.info 
     -->page.tpl.php 
ShellScripts 
    -->scriptA.sh 
    -->scriptB.sh 
legacyPerlScripts 
    -->script1.pl 
    -->script2.pl 

Es gibt kein großes Entwicklungsteam; Ich entwickle alle Module und Themen selbst. Die Module und Themen sind etwas unabhängig und jede hat ihre eigene Versionsnummer. Einige große Aufgaben erfordern jedoch möglicherweise ein Upgrade auf mehrere Module. Außerdem sollten die Module, Themen und Skripts zusammen bereitgestellt werden, z. Es wäre keine gute Idee, die aktuelle Version von Modul A mit einer älteren Version von Modul B zu verwenden, da Modul B von einer neuen Funktion in Modul A abhängen kann.

Was ist die beste Vorgehensweise für die Verwendung von git für die Revision Steuerung? Die Optionen, wie ich sie sehe sind:

1. Setzen Sie alles in einem großen, monolithischen Repository.
2. Erstellen Sie ein separates Repository für jedes Modul, Thema und Skriptverzeichnis.
3. Verwenden Sie git-slave (gits), um Teilprojekte für jedes Modul, Thema und Skriptverzeichnis zu erstellen.
4. git Submodule
5. git Teilbäume

Welche dieser fünf Optionen ist die am häufigsten für eine Web-Entwicklungsprojekt wie diesem?

Answer 1

Submodule sind eine schlechte Lösung für eng gekoppelten Code. Wir hatten zwei Hauptprojekte, die ein Teilprojekt für Datenbankmigrationen teilten, von denen beide Projekte abhingen. Wir haben dies mit Submodulen implementiert, und die Schritte zum Vornehmen von Änderungen an den Migrationen waren etwa folgendermaßen:

Die Änderungen an das Submodul übergeben.

Drücken Sie die Änderungen zum Ursprung.

Sichern Sie das Superprojekt, in dem Sie sich gerade befanden.

Geben Sie das neue Submodul ein und drücken Sie es.

Wechseln Sie in die Kopie des Submoduls des anderen Superprojekts.

Ziehen Sie die neuesten Änderungen vom Ursprung.

Zurück zu , dass Superprojekt.

Commit und drücken Sie das neue Submodul ref.

Darüber hinaus mussten Sie immer sicherstellen, dass Sie für alle drei Projekte auf dem richtigen Zweig waren. Es war ein großer Schmerz. Submodule wurden einfach nicht für diese Art von Entwicklung gemacht. Letztendlich haben wir die Datenbankmigrationen zu einem der beiden Hauptprojekte gemacht und der Code wurde nicht mehr geteilt (er wurde nur als Annehmlichkeit geteilt).

Ich habe in Unterbaumverschmelzung untersucht, aber es sah nur marginal besser als Submodule aus.

Es klingt wirklich so, als sollten Sie es einfach als ein Repository belassen und Verzweigungen und Tagging verwenden, um die verschiedenen Versionen Ihrer verschiedenen Module zu verwalten, vor allem, wenn dies ohnehin zusammen implementiert werden soll.

Answer 2

Halten Sie alles in einem Repository. Sie haben bereits alles nach Verzeichnis sortiert. Wenn Sie möchten, können Sie für jeden Client separate Zweigverfolgungsfunktionen verwenden, bei denen Änderungen an den Verzeichnissen vorgenommen werden können.