Les Git Submodules sont une fonctionnalité de Git qui permet d’intégrer un dépôt Git à l’intérieur d’un autre dépôt. Cette approche est particulièrement utile lorsque plusieurs projets doivent partager une bibliothèque commune tout en gardant un contrôle précis sur les versions utilisées.
Dans cet article, nous allons comprendre ce qu’est un Git Submodule, comment il fonctionne, ainsi que ses avantages et ses limites dans un projet logiciel.
Dans de nombreux projets logiciels, plusieurs applications ou services partagent une partie de leur code. Il peut s’agir :
Par exemple, une équipe peut maintenir plusieurs microservices qui utilisent la même librairie interne. Cette librairie peut gérer l’authentification, communiquer avec une API externe ou implémenter certaines fonctionnalités métier.
La gestion de ce code partagé devient rapidement complexe.
Une première approche consiste à copier le code dans chaque dépôt. Cette solution semble simple au départ, mais elle crée rapidement des problèmes :
Une autre approche consiste à placer ce code dans un dépôt Git séparé afin de le versionner indépendamment.
Cependant, une question apparaît rapidement :
Comment intégrer ce dépôt externe dans plusieurs projets tout en contrôlant la version utilisée ?
Les Git Submodules apportent une solution à ce problème. Ils permettent d’intégrer un dépôt Git dans un autre dépôt tout en conservant son historique et sa gestion de version.
Exemple de structure avec code partagé :
Chaque service utilise une bibliothèque commune maintenue dans un dépôt séparé.
Avec Git Submodules, un projet peut ressembler à ceci :
Le dossier shared-library correspond alors à un dépôt Git externe intégré dans le projet.
Les Git Submodules permettent d’intégrer un dépôt Git dans un autre dépôt tout en conservant leur indépendance (voir la documentation).
Le dépôt intégré possède :
Lorsque l’on ajoute un submodule, Git ne copie pas simplement les fichiers. Le dépôt principal enregistre une référence vers un commit précis du dépôt externe.
Cela signifie que le projet parent pointe vers une version exacte du submodule.
Tous les développeurs utilisent donc la même version du code partagé.
Git stocke les informations du submodule dans le fichier .gitmodules .
Ce fichier contient notamment :
Les Git Submodules permettent de maintenir une bibliothèque ou un composant partagé dans un dépôt dédié.
Les projets qui en dépendent peuvent ensuite intégrer ce dépôt sous forme de submodule.
Chaque projet choisit alors la version du composant qu’il souhaite utiliser en pointant vers un commit précis.
Cette approche offre plusieurs avantages :
Git enregistre à la fois :
Il devient donc possible de reproduire exactement l’état d’un projet à un instant donné.
Voici les commandes les plus utilisées pour travailler avec les Git Submodules.
Ajouter un submodule
git submodule add https://github.com/organisation/shared-library.git libs/shared-library
Cette commande :
Cloner un projet avec ses submodules
git clone --recurse-submodules https://github.com/organisation/project.git
Cette commande permet de récupérer :
Initialiser les submodules après un clone (si le projet a déjà été cloné)
git submodule update --init --recursive
Cette commande télécharge tous les submodules nécessaires.
Les Git Submodules offrent plusieurs avantages pour gérer du code partagé :
Mais malgré ces avantages, les Git Submodules introduisent aussi certaines contraintes :
Les Git Submodules ne sont pas la seule solution pour partager du code.
Dans un monorepo, plusieurs projets sont regroupés dans un seul dépôt.
Avantages :
Inconvénient :
https://docs.github.com/en/get-started/using-git/about-git-subtree-merges
Git Subtree permet d’intégrer directement le contenu d’un dépôt dans un autre.
Avantage :
Inconvénient :
Une autre approche consiste à publier une bibliothèque sous forme de package.
Exemples :
Les projets peuvent alors consommer cette bibliothèque comme une dépendance classique.
