Comprendre et travailler avec des sous-modules en Git

Les projets logiciels modernes reposent principalement sur les résultats du travail d'autres projets. Si quelqu'un d'autre a écrit d'excellentes solutions et que vous réinventez la roue de votre code, ce serait une énorme perte de temps. C'est pourquoi de nombreux projets utilisent du code tiers, tels que des bibliothèques ou des modules.

git, le système de contrôle de version le plus populaire au monde, fournit un moyen élégant et puissant de gérer ces dépendances. Son concept de «sous-modules» nous permet d'inclure et de gérer des bibliothèques tierces tout en les gardant clairement séparés de notre propre code.

Cet article expliquera pourquoi les sous-modules Git sont si utiles, que sont exactement et comment ils fonctionnent.

Points clés

Les sous-modules
• git sont un moyen puissant et simple de gérer les bibliothèques tierces d'un projet et de les isoler clairement à partir de la base de code principale. Ce sont des référentiels GIT standard placés dans un autre référentiel GIT parent.
• L'ajout de sous-modules à un projet implique la création d'un dossier séparé, puis en utilisant la commande "Git Subdule Add", suivie de l'URL de la bibliothèque souhaitée. Cela clones le référentiel dans le projet en tant que sous-module, le séparant du référentiel du projet principal.
• Lors du clonage d'un projet contenant un sous-module GIT, le sous-module sera automatiquement initialisé et cloné à l'aide de l'option "--Recurse-Submodules" dans la commande "Git Clone". Si vous ne faites pas cela, le dossier sous-module sera vide après le clonage et doit être rempli de "mise à jour du sous-module GIT - Init --Recursive".
• Dans le sous-module Git, une version spécifique est vérifiée, pas une branche, permettant un contrôle complet sur le code exact utilisé dans le projet principal. La mise à jour d'un sous-module implique l'utilisation de "Git Subdodule Update", suivi du nom du sous-module.

Garder la séparation du code

pour illustrer clairement pourquoi les sous-modules Git sont une structure précieuse, regardons un cas où n'a pas de sous-modules . Lorsque vous devez inclure du code tiers, tel que les bibliothèques open source, vous pouvez choisir un moyen facile: il suffit de télécharger le code à partir de GitHub et de le mettre quelque part dans votre projet. Bien que cette méthode soit très rapide, elle n'est certainement pas propre pour plusieurs raisons: En copiant de force le code tiers dans votre projet, vous mélangez en fait plusieurs projets dans un seul projet. La ligne entre votre propre projet et les projets d'autrui (bibliothèque) commence à se brouiller.

chaque fois que vous avez besoin de mettre à jour le code de la bibliothèque (car son mainteneur fournit une excellente nouvelle fonctionnalité ou corrige un bogue sérieux), vous devez télécharger, copier et coller à nouveau. Cela deviendra bientôt un processus fastidieux.

La règle générale de "séparer différentes choses" dans le développement de logiciels n'est pas déraisonnable. Cela est particulièrement vrai pour gérer le code tiers dans vos propres projets. Heureusement, le concept de sous-module de Git est conçu pour ces situations.

• Bien sûr, les sous-modules ne sont pas la seule solution à de tels problèmes. Vous pouvez également utiliser une variété de systèmes "Gestionnaire de packages" fournis par de nombreuses langues et cadres modernes. Il n'y a rien de mal à faire ça!

  Cependant, vous pouvez penser à l'architecture du sous-module de Git avec certains avantages:

  Les sous-modules
  • fournissent des interfaces cohérentes et fiables - sans cesse de la langue ou du cadre que vous utilisez. Si vous utilisez plusieurs technologies, chacune peut avoir son propre gestionnaire de packages et son propre ensemble de règles et de commandes. D'un autre côté, les sous-modules fonctionnent toujours de la même manière.
  • Probablement tout le code n'est probablement pas disponible via le gestionnaire de packages. Peut-être que vous voulez simplement partager votre propre code entre deux projets - dans ce cas, le sous-module peut fournir le processus le plus simple.

  L'essence du sous-module git

  Les sous-modules

  dans Git ne sont en fait que des référentiels GIT standard. Il n'y a pas d'innovation sophistiquée, juste le même référentiel Git que nous connaissons tous très bien. Cela fait également partie de la puissance des sous-modules: ils sont si puissants et directs parce qu'ils sont si "secs" d'un point de vue technique et bien testés.

  La seule chose qui fait d'un référentiel git un module enfant est qu'il est situé à l'intérieur d'un autre parent git Repository .

  Autre que cela, le sous-module GIT est toujours un référentiel entièrement fonctionnel: vous pouvez faire tout ce que vous savez déjà du travail GIT "normal" - de la modification des fichiers à la validation, à la tir et à la poussée. Tout dans le sous-module est possible.

  Ajouter le sous-module

  Prenons un exemple classique comme exemple, supposons que nous voulons ajouter une bibliothèque tierce au projet. Il est logique de créer un dossier séparé pour stocker un tel contenu avant d'obtenir un code:

  <code class="language-bash">$ mkdir lib
  $ cd lib</code>

  Maintenant, nous sommes prêts à importer un code tiers dans notre projet à l'aide de sous-modules de manière ordonnée. Supposons que nous ayons besoin d'une petite bibliothèque JavaScript "Convertisseur de fuseau horaire":

  <code class="language-bash">$ git submodule add https://github.com/spencermountain/spacetime.git</code>

  Lorsque nous exécutons cette commande, Git clones le référentiel dans notre projet en tant que sous-module:

  <code>Cloning into 'carparts-website/lib/spacetime'...
  remote: Enumerating objects: 7768, done.
  remote: Counting objects: 100% (1066/1066), done.
  remote: Compressing objects: 100% (445/445), done.
  remote: Total 7768 (delta 615), reused 975 (delta 588), pack-reused 6702
  Receiving objects: 100% (7768/7768), 4.02 MiB | 7.78 MiB/s, done.
  Resolving deltas: 100% (5159/5159), done.</code>

  Si nous regardons notre dossier de copie de travail, nous pouvons voir que le fichier de bibliothèque est réellement arrivé dans notre projet.

  

  Vous pourriez demander: "Quelle est la différence?" La principale différence est qu'ils sont inclus dans leur propre référentiel git

  ! Si nous téléchargeons simplement certains fichiers, les jetons dans notre projet et les engageons - comme le reste de nos projets - ils feront partie du même référentiel GIT. Cependant, le sous-module garantit que les fichiers de bibliothèque ne sont pas "divulgués" dans le référentiel de notre projet principal. Voyons ce qui se passe d'autre: un nouveau fichier .gitmodules a été créé dans le dossier racine du projet principal. Ce qui suit est son contenu:

  <code class="language-bash">$ mkdir lib
  $ cd lib</code>

  Ce fichier .gitmodules est l'un des nombreux emplacements des sous-modules dans les projets de suivi GIT. L'autre est .git / config, qui se termine maintenant comme suit:

  <code class="language-bash">$ git submodule add https://github.com/spencermountain/spacetime.git</code>

  Enfin, Git conserve également une copie du référentiel .git de chaque sous-module dans le dossier .git / modules interne.

  Tous ce sont des détails techniques dont vous n'avez pas à vous souvenir. Cependant, il peut être utile de comprendre que le maintien interne des sous-modules Git est assez complexe. C'est pourquoi une chose est importante à retenir: ne modifiez pas manuellement la configuration du sous-module GIT! Si vous souhaitez déplacer, supprimer ou exploiter des sous-modules, faites-vous une faveur, n'essayez pas cela manuellement. Vous pouvez utiliser les commandes GIT appropriées ou une interface graphique de bureau GIT comme "Tower" et il gérera ces détails pour vous.

  Voyons le statut du projet principal après avoir ajouté des sous-modules:

  Comme vous pouvez le voir, Git traite l'ajout de sous-modules comme les mêmes changements que les autres changements. Nous devons donc commettre ce changement comme tout autre changement:

  <code>Cloning into 'carparts-website/lib/spacetime'...
  remote: Enumerating objects: 7768, done.
  remote: Counting objects: 100% (1066/1066), done.
  remote: Compressing objects: 100% (445/445), done.
  remote: Total 7768 (delta 615), reused 975 (delta 588), pack-reused 6702
  Receiving objects: 100% (7768/7768), 4.02 MiB | 7.78 MiB/s, done.
  Resolving deltas: 100% (5159/5159), done.</code>

  <code>[submodule "lib/spacetime"]
    path = lib/spacetime
    url = https://github.com/spencermountain/spacetime.git</code>

  Clone Le projet contenant le sous-module GIT

  Dans notre exemple ci-dessus, nous avons ajouté un nouveau sous-module au référentiel GIT existant. Mais, "à son tour", que se passe-t-il lorsque vous clonez un référentiel qui contient déjà le sous-module

  ?

  Si nous exécutons un clone Git normal & lt; URL distant & gt; sur la ligne de commande, nous téléchargerons le projet principal - mais nous constaterons que tout dossier de sous-module est vide! Cela prouve une fois de plus que les fichiers sous-modules sont indépendants et ne sont pas inclus dans leur référentiel parent.

  Dans ce cas, pour remplir le sous-module après le clonage de son référentiel parent, vous pouvez simplement faire la mise à jour du sous-module GIT - Init - réécursive. Une meilleure façon consiste à ajouter directement l'option --Recurse-Submodules lorsque le premier clone Git est appelé.

  Version de paiement

  Dans les référentiels Git "normaux", nous vérifions généralement les branches. En utilisant Git Checkout & lt; Nom de la branche & gt; ou un commutateur GIT mis à jour & lt; Nom de la branche & gt;, nous disons à Git ce que devrait être notre branche actuellement active. Lorsqu'un nouveau commit est fait sur cette branche, le pointeur de tête se déplacera automatiquement

  vers le dernier engagement. Il est important de comprendre cela - parce que les sous-modules Git fonctionnent différemment! Dans les sous-modules, nous vérifions toujours une version spécifique - pas une branche! Même si vous exécutez des commandes similaires à Git Checkout Main dans un sous-module, en arrière-plan, le dernier

  COMMISSE

  actuel sur cette branche est enregistré - pas la branche elle-même. Bien sûr, ce comportement n'est pas une erreur. Considérez ceci: lorsque vous incluez des bibliothèques tierces, vous souhaitez avoir un contrôle total sur le code exact que vous utilisez dans votre projet principal. C'est génial lorsque le mainteneur de la bibliothèque publie une nouvelle version ... mais vous ne voulez pas nécessairement utiliser cette nouvelle version automatiquement dans votre projet. Parce que vous ne savez pas si ces nouveaux modifications briseront votre projet

  !

  Si vous souhaitez savoir quelle version votre sous-module utilise, vous pouvez demander ces informations dans le projet principal:

  <code class="language-bash">$ mkdir lib
  $ cd lib</code>

  Cela renverra la version actuellement vérifiée par notre sous-module Lib / Spacetime. Il nous permet également de savoir que cette version est une balise appelée "6.16.3". Il est courant d'utiliser fortement les balises lors de l'utilisation de sous-modules Git.

  Supposons que vous souhaitiez que votre sous-module utilise une ancienne version de , marqué "6.14.0". Tout d'abord, nous devons modifier le répertoire afin que nos commandes GIT soient exécutées dans le contexte du sous-module, et non notre projet principal. Ensuite, nous pouvons simplement exécuter Git Checkout avec le nom de la balise:

  <code class="language-bash">$ git submodule add https://github.com/spencermountain/spacetime.git</code>

  Si nous retournons maintenant à notre projet principal et exécutons à nouveau le statut de sous-module GIT, nous verrons notre caisse:

  <code>Cloning into 'carparts-website/lib/spacetime'...
  remote: Enumerating objects: 7768, done.
  remote: Counting objects: 100% (1066/1066), done.
  remote: Compressing objects: 100% (445/445), done.
  remote: Total 7768 (delta 615), reused 975 (delta 588), pack-reused 6702
  Receiving objects: 100% (7768/7768), 4.02 MiB | 7.78 MiB/s, done.
  Resolving deltas: 100% (5159/5159), done.</code>

  Venez afficher la sortie: le symbole avant le hachage SHA-1 nous dit que la version du sous-module est différente de la version actuellement stockée dans le référentiel parent. Puisque nous venons de changer la version vérifiée, cela semble correct.
  appeler le statut Git dans notre projet principal nous informe maintenant également de ce fait:

  <code>[submodule "lib/spacetime"]
    path = lib/spacetime
    url = https://github.com/spencermountain/spacetime.git</code>

  Vous pouvez voir que Git traite les pointeurs de sous-module en mouvement comme les mêmes changements que les autres changements: si nous voulons le stocker, nous devons le valider dans le référentiel:

  <code>[submodule "lib/spacetime"]
    url = https://github.com/spencermountain/spacetime.git
    active = true</code>

  Mettre à jour le sous-module git

  Dans les étapes ci-dessus, nous

  nous-mêmes a déplacé le pointeur sous-module: nous sommes ceux qui choisissent de consulter différentes versions, de la soumettre et de la pousser vers le référentiel distant de notre équipe. Mais que se passe-t-il si notre collègue modifiait la version du sous-module - peut-être parce qu'une nouvelle version intéressante du sous-module a été publiée et que notre collègue a décidé de l'utiliser dans notre projet (après des tests approfondis, bien sûr ...).

  EXÉCUTONS UNE PULLE GIT IMPORTANT dans le projet principal - parce que nous pouvons le faire souvent - pour obtenir de nouveaux modifications d'un référentiel distant partagé:

  <code class="language-bash">$ git status
  On branch master
  Changes to be committed:
    (use "git restore --staged <file>..." to unstage)
    new file:   .gitmodules
    new file:   lib/spacetime</file></code>

  L'avant-dernière ligne indique que quelque chose dans le sous-module a été modifié. Mais regardons de plus près:

  <code class="language-bash">$ git commit -m "Add timezone converter library as a submodule"</code>

  Je crois que vous vous souvenez encore de ce petit nombre: cela signifie que le pointeur sous-module a bougé! Pour mettre à jour notre version de caisse locale vers la version "officielle" sélectionnée par nos coéquipiers, nous pouvons exécuter la commande de mise à jour:

  <code class="language-bash">$ git submodule status
     ea703a7d557efd90ccae894db96368d750be93b6 lib/spacetime (6.16.3)</code>

  D'accord! Nos sous-modules sont maintenant vérifiés à la version enregistrée dans notre référentiel de projet principal!

  en utilisant le sous-module git

  Nous avons couvert les blocs de construction de base à l'aide de sous-modules Git. Les autres workflows sont très standard!
  Par exemple, la vérification des nouvelles modifications dans les sous-modules est comme dans tout autre référentiel GIT: vous exécutez la commande git fetch dans le référentiel de sous-module et si vous souhaitez utiliser des mises à jour, vous pouvez alors exécuter quelque chose comme Git Pull Origin après Main Main Main commande.
  La modification des sous-modules peut également fonctionner pour vous, surtout si vous gérez vous-même le code de la bibliothèque (car il s'agit d'une bibliothèque interne, pas d'un tiers). Vous pouvez utiliser des sous-modules comme vous le feriez avec n'importe quel autre référentiel GIT: vous pouvez apporter des modifications, les engager, les pousser, etc.

  Obtenez la puissance de Git

  Git a des fonctionnalités puissantes dans les coulisses. Cependant, de nombreux outils avancés, tels que les sous-modules Git, ne sont pas bien connus. De nombreux développeurs ont raté beaucoup de fonctionnalités puissantes, ce qui est vraiment dommage!

  Si vous souhaitez approfondir certaines autres technologies avancées Git, je recommande fortement la "boîte à outils avancée Git": il s'agit d'une courte collection vidéo (gratuite!) Qui vous présentera un réflog, une rebase interactive, des cerises comme des sujets comme des sujets comme Cueillette et même stratégies de ramification.

  Je vous souhaite un meilleur développeur!

  Des questions fréquemment posées sur les sous-modules Git

  Qu'est-ce qu'un sous-module Git? Le sous-module GIT est un moyen d'inclure un autre référentiel GIT en tant que sous-répertoire dans votre propre référentiel GIT. Il vous permet de maintenir un référentiel séparé en tant que sous-projet dans le projet principal.

  Pourquoi utiliser le sous-module Git? Les sous-modules git sont utiles pour fusionner des référentiels externes dans votre projet, surtout si vous souhaitez séparer leur historique de développement du projet principal. Ceci est très bénéfique pour gérer les dépendances ou y compris les bibliothèques externes.

  Quelles informations sont stockées dans le projet principal sur le sous-module? Le projet principal stocke l'URL et engagez le hachage du sous-module dans une entrée spéciale dans le référentiel parent. Cela permet à toute personne clonage le projet principal de cloner les sous-modules référencés.

  Comment cloner un référentiel GIT contenant des sous-modules? Lors du clonage d'un référentiel contenant des sous-modules, vous pouvez automatiquement initialiser et cloner les sous-modules à l'aide de l'indicateur - réécursif de la commande GIT Clone. Alternativement, vous pouvez utiliser la mise à jour du sous-module GIT - init après le clonage.

  Puis-je nicher sous-modules? Oui, Git prend en charge les sous-modules imbriqués, ce qui signifie que les sous-modules peuvent contenir ses propres sous-modules. Cependant, la gestion des sous-modules imbriqués peut se compliquer et vous devez vous assurer que chaque sous-module est correctement initialisé et mis à jour.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!