Sous-module Git vs clone Git

Je travaille sur un projet open source sur GitHub.

Il a un sous-répertoire / fournisseur dans lequel il a une copie de plusieurs bibliothèques externes. Le responsable d'origine du projet a mis à jour ce répertoire avec une copie plus récente de la bibliothèque externe de temps en temps.

Un développeur m'a envoyé une pull request avec l'idée de remplacer cette copie par le sous-module git .

Et je me demande si c'est une bonne idée ou non.

Git submodule Avantages:

• Les sous-modules ont été spécialement conçus pour des scénarios similaires
• Il supprime la possibilité d'un commit accidentel au vendeur qui sera écrasé lors de la prochaine mise à jour

Sous-module Git Contre:

• Il semble que les sous-modules git poussent la complexité du responsable à une personne qui clonera / tirera le projet (étapes supplémentaires requises après avoir cloné pour commencer à travailler avec le projet: "git submodule init", "git submodule update"

Quel est ton opinion là-dessus?

Encore une chose. Ce problème est une bibliothèque de taille relativement petite avec des dépendances externes très limitées. Je pense que tout outil de construction serait exagéré pour l'instant.

Une alternative à un sous-module est d'utiliser git subtree. Cela donne les avantages git submodulemais sans pousser la complexité à l'utilisateur final. Le référentiel tiers est fusionné dans l'arborescence principale du projet, mais certaines métadonnées sont stockées de manière à ce que vous puissiez:

• extraire le référentiel tiers ultérieurement, si des modifications intéressantes ont été apportées
• fusionner les nouvelles mises à jour du référentiel tiers (notez la fusion , pas l'écrasement)

Pour les utilisateurs de Git qui ne sont pas assez sophistiqués pour comprendre les sous-modules, l'approche des sous-arbres rend l'obtention d'un clone de votre projet plus difficile que tout autre clone. Un bref texte descriptif de la documentation:

Les sous-arborescences permettent d'inclure des sous-projets dans un sous-répertoire du projet principal, incluant éventuellement l'historique complet du sous-projet.

Par exemple, vous pouvez inclure le code source d'une bibliothèque en tant que sous-répertoire de votre application.

Les sous-arbres ne doivent pas être confondus avec les sous-modules, qui sont destinés à la même tâche. Contrairement aux sous-modules, les sous-arbres n'ont pas besoin de constructions spéciales (comme les fichiers .gitmodule ou les liens git) présents dans votre référentiel, et n'obligent pas les utilisateurs finaux de votre référentiel à faire quelque chose de spécial ou à comprendre le fonctionnement des sous-arbres. Un sous-arbre est juste un sous-répertoire qui peut être validé, ramifié et fusionné avec votre projet comme vous le souhaitez.

J'avais mis en place un projet au travail en utilisant des sous-modules, et les problèmes avec la mise à jour des sous-modules dans les clones de tout le monde étaient trop de travail. J'ai récemment changé pour utiliser des sous-arbres partout et ces problèmes ont disparu.

Notez que git-subtree fait partie du git/contribrépertoire et doit être installé séparément.

Un inconvénient de l'utilisation des sous-modules est que les archives tar ou les archives zip sur Github (et de nombreux autres services) n'incluent pas les sources des sous-modules. Autrement dit, les archives ne sont pas autonomes. C'est un problème si le référentiel est petit et n'a pas vraiment de script de construction, comme un site HTML statique dépendant d'une bibliothèque JavaScript.

C'est un endroit idéal pour utiliser des sous-modules. Ils réduisent la taille et la complexité de votre référentiel et facilitent la mise à jour des bibliothèques externes vers une nouvelle version.

Ils ne sont pas difficiles à comprendre comment utiliser, et ils sont assez couramment utilisés dans cette situation, alors notez simplement dans le fichier README du projet que vous utilisez des sous-modules et que faire, et les gens devraient être en mesure de comprendre IT out. La première fois que j'ai rencontré un référentiel avec un sous-module, je l'ai mis en service en 10 à 15 minutes et je n'ai jamais eu de problème pour savoir quoi faire depuis.

L'utilisation de sous-modules vous empêche d'apporter des modifications locales au code et crée une dépendance sur le référentiel externe. Si vous êtes sûr que vous ne voudrez jamais personnaliser une bibliothèque ou faire des corrections de bugs locaux et que le serveur externe sera toujours disponible lorsque vous voulez cloner une nouvelle copie, c'est la voie à suivre.

En bref - voulez-vous simplement utiliser les bibliothèques ou les considérez-vous comme faisant partie de votre base de code? S'ils ne sont pas «votre» code, pourquoi sont-ils en contrôle de version et pas seulement quelque chose que vous devez avoir installé?