J’estime que l’utilisation de sous-modules Git est gênante pour mon flux de travail de développement. J'ai entendu parler de Git Subtree et Gitslave.
Ce qui vous convient le mieux dépend de vos besoins, de vos souhaits et de votre flux de travail. Ils sont, à certains égards, semi-isomorphes, mais certains sont beaucoup plus faciles à utiliser que d'autres pour des tâches spécifiques.
gitslave est utile lorsque vous contrôlez et développez sur les sous-projets plus ou moins en même temps que le superprojet, et surtout lorsque vous souhaitez baliser, relier, pousser, tirer, etc. tous les référentiels en même temps. gitslave n'a jamais été testé sur des fenêtres que je connaisse. Cela nécessite Perl.
git-submodule est préférable si vous ne contrôlez pas le sous-projet ou si vous souhaitez plus spécifiquement réparer le sous-projet à une révision spécifique, même si le sous-projet est modifié. git-submodule est une partie standard de git et fonctionnerait donc sous windows.
git-subtree fournit une interface pour la stratégie de fusion des sous-arbres intégrée de git. Il est préférable que vous préfériez disposer d’un historique git "unifié" à référentiel unique. Contrairement à la stratégie de fusion des sous-arbres, il est plus facile d'exporter les modifications apportées aux différentes arborescences (de répertoires) dans le projet d'origine, mais ce n'est pas aussi automatique qu'avec gitslave ou même git-submodule.
repo est en théorie similaire à gitslave, mais pas aussi bien documenté pour les opérations non-Android que j'ai trouvées. Il est assez dédié au modèle de développement de Google Android et ne supporte nativement que quelques commandes git (bien que vous puissiez exécuter des commandes arbitraires) et le support natif limité ne supporte pas, par exemple, un référentiel centralisé pour pousser et extraire une branche semble assez difficile.
le kit mr de kitenet est ce que vous voudriez utiliser si vous utilisez plusieurs systèmes de contrôle de version, mais il est généralement limité aux superprojets git-only en raison de son approche avec le plus petit dénominateur commun. Il existe des moyens d’exécuter des commandes arbitraires, mais elles ne sont pas aussi bien intégrées.
Nous avons rencontré un problème similaire lors de l'utilisation de sous-modules Git dans des projets où nous avions des dépendances dans diverses langues. Pour y faire face, nous avons développé et ouvert un outil appelé MDLR ("Modular") qui vous donne des dépendances déclarées de Git contrôlées par la version, avec des fonctionnalités similaires aux sous-modules Git, mais sans le workflow gênant. Vous pouvez l'installer et gérer vos dépendances avec les instructions/téléchargements sur le GitHub repo
J'utilise actuellement des sous-modules pour le développement et pas seulement pour relier des bibliothèques tierces. Il existe des moyens de rendre la vie plus facile avec les sous-modules, en particulier lorsqu'ils sont la source de conflits de fusion ou de rebasement. Regardez dans ls-tree pour obtenir les 2 commits impliqués dans un conflit dans le sous-module. C’est probablement la partie la plus difficile des sous-modules à traiter. Pour le moment, les scripts faciliteront grandement cette tâche. Les futures versions de Git devraient avoir un meilleur support natif pour les gérer.
J'espère que cela t'aides.