gitaarik/git_submodules.md (Français)

pourquoi les sous-modules?

dans Git, vous pouvez ajouter un sous-module à un dépôt. Il s’agit essentiellement d’arepository intégré dans votre référentiel principal. Cela peut être veryuseful. Quelques avantages de l’utilisation des submodules:

• Vous pouvez séparer le code en différents référentiels.

  utile si vous avez une base de code avec de gros composants, vous pouvez faire d’acomponent un sous-module. De cette façon, vous aurez un journal git plus propre (les commits sont spécifiques à un certain composant).,

• Vous pouvez ajouter le sous-module de plusieurs référentiels.

  utile si vous avez plusieurs référentiels qui partagent les mêmes composants. Avec cette approche, vous pouvez facilement mettre à jour ceuxcomposants dans tous les référentiels qui les ont ajoutés en tant que sous-module.C’est beaucoup plus pratique que de copier-coller le code dans therepositories.

Basics

lorsque vous ajoutez un sous-module dans Git, vous n’ajoutez pas le code de thesubmodule au référentiel principal, vous n’ajoutez que des informations sur thesubmodule qui est ajouté au référentiel principal., Cette informationdécrit qui commit le sous-module pointe. De cette façon, le code du sous-module  » s « NE SERA PAS automatiquement mis à jour si le sous-module »srepository est mis à jour. C’est bien, car votre code pourrait ne pas fonctionner avec le dernier commit du sous-module, il empêche unexpectedbehaviour.,

ajout d’un sous-module

Vous pouvez ajouter un sous-module à un référentiel comme ceci:

avec la configuration par défaut, cela vérifiera le code du référentielawesome_submodule.git dans le répertoirepath_to_awesome_submodule, et ajoutera des informations au référentiel principal sur ce sous-module, qui contient le commit vers lequel pointe le sous-module,qui sera le commit actuel de la branche par défaut (généralement la branchemaster) au moment de l’exécution de cette commande.,

Après cette opération, si vous faites un git status vous allez voir deux fichiers dans Changes to be committed liste: la balise .gitmodules fichier et le chemin le sous-module. Lorsque vous validez et poussez ces fichiers, vous validez / poussez le sous-module à l’origine.

obtenir le code du sous-module

Si un nouveau sous-module est créé par une personne, les autres personnes de l’équipe doivent initier ce sous-module. Vous devez d’abord obtenir l’information sur le sous-module, celle-ci est récupérée par ungit pullnormal., S’il y a de nouveaux sous-modules, vous le verrez dans la sortie degit pull. Ensuite, vous devrez les initier avec:

cela extraira tout le code du sous-module et le placera dans le répertoire pour lequel il est configuré.

Si vous avez cloné un référentiel qui utilise des sous-modules, vous devriez également exécuter cette commande pour obtenir le code du sous-module. Ceci n’est pas automatiquement fait par git clone.

pousser les mises à jour dans le sous-module

le sous-module est juste un dépôt séparé., Si vous voulez y apporter des modifications, vous devez apporter les modifications dans ce référentiel et les pousser comme dans un référentiel Git normal (exécutez simplement les commandes git dans le répertoire du module). Cependant, vous devez également informer le mainrepository que vous avez mis à jour le référentiel du sous-module et que vous utilisez le dernier commit du référentiel du sous-module. Parce que si vous effectuez de nouveaux commits dans un sous-module, le référentiel principal pointera toujours vers l’ancien commit.,

donc, si vous souhaitez également avoir ces modifications dans votre référentiel principal, vous devez indiquer au référentiel principal d’utiliser le dernier commit de thesubmodule. Maintenant, comment faites-vous cela?

Vous avez donc apporté des modifications au référentiel du sous-module et les avez validées dans son référentiel. Si maintenant, vous faites un git status dans le mainrepository, vous allez voir que le sous-module est dans la liste Changes not staged for commit et il a le texte (modified content) derrière elle.Cela signifie que le code du sous-module est extrait sur une validation différente de celle pointée par le référentiel principal., Pour que le référentiel principal pointe vers ce nouveau commit, il vous suffit d’ajouter ce changement avec git add, puis de le valider et de le pousser.

mise à jour de vos sous-modules

Si quelqu’un a mis à jour un sous-module, les autres membres de l’équipe doivent mettre à jour le code de leurs sous-modules. Cela n’est pas fait automatiquement pargit pull, car avec git pull, il ne récupère que les informations indiquant que le sous-module pointe vers un autrecommit, mais ne met pas à jour le code du sous-module., Pour mettre à jour le code de vos sous-modules, vous devez exécuter:

que se passe-t-il si vous n’exécutez pas cette commande?

Si vous n’exécutez cette commande, le code de votre sous-module est checkedout à un ancien commit. Quand vous faites git status vous verrez thesubmodule dans le Changes not staged for commit liste avec le texte(modified content) derrière elle. Ce n’est pas parce que vous avez changé le code de thesubmodule, mais parce que son code est extrait à un differentcommit. Git voit donc cela comme un changement, mais en fait, vous n’avez tout simplement pas mis à jour le code du sous-module., Donc, si vous travaillez avecsubmodules, ne pas oublier de garder vos sous-modules à jour.

le rendre plus facile pour tout le monde

Il est parfois ennuyeux si vous oubliez d’initier et de mettre à jour votresubmodules. Heureusement, il existe quelques astuces pour le rendre plus facile:

cela mettra à jour les sous-modules, et s’ils ne sont pas encore initiés, les initialisera.

Vous pouvez également avoir des sous-modules à l’intérieur des sous-modules., Dans ce cas, vous »voulez mettre à jour/lancer les sous-modules récursivement:

c’est beaucoup à taper, donc vous pouvez créer un alias:

maintenant chaque fois que vous exécutez git update, il exécutera un git pull anda git submodule update --init --recursive, mettant ainsi à jour tout le code dans votre projet.

---