Sous-modules Git et paquets partagés en équipe

Les sous-modules Git sont utiles pour des dépôts partagés avec leur propre cycle de vie. Cela inclut design systems, outils internes, modèles ou paquets sans flux de publication séparé.

• un projet utilise une autre version du code partagé qu’un autre
• les mises à jour restent difficiles à suivre dans le projet principal
• des sous-répertoires importants manquent après le clone
• la livraison s’arrête parce que le module manque dans l’automatisation

Préparer un projet existant avec des sous-modules

Cette étape récupère le contenu manquant du sous-module directement lors du clone ou ensuite dans le projet.

Ajouter un dépôt partagé comme sous-module

Cela fixe l’emplacement du sous-module dans le projet et la branche de référence. Le projet principal enregistre toujours un commit précis du sous-module.

• les changements restent traçables
• les mises à jour se font de manière consciente et contrôlée
• le projet principal doit reprendre explicitement chaque nouvel état

Maintenir les états du sous-module dans l’équipe

Ce flux garde projet principal et sous-module au même état et rend les changements traçables dans l’équipe.

Charger les sous-modules en automatisation

Cas d’usage des sous-modules

Les sous-modules conviennent à des dépôts partagés avec un cycle de vie propre et une séparation claire du projet principal.

• outils internes
• modèles et squelettes
• collections de configuration partagées
• design systems ou ressources privées avec leur propre cycle de vie

Bénéfice dans le travail quotidien de l’équipe

Des états clairs du sous-module rendent les dépendances partagées traçables et gardent une relation vérifiable entre projet principal et dépôt enfant.