Qu'est-ce que la «vente»?

La vente est un moyen d'intégrer le travail des autres dans le vôtre. C'est l'opposé de «lier» une bibliothèque tierce. Au lieu d'avoir cette bibliothèque comme dépendance, l'application utilise cette bibliothèque en tant que partie de son propre code source et conserve ce code `` à l'intérieur '' lui-même.

Normalement, la vente se fait par l'outillage linguistique: bundler, cargo, pip, etc. Mais parfois, vous devez vendre quelque chose qui n'est couvert par aucun jeu d'outils existant, ou quelque chose de multilingue, qu'il est impossible de trouver l'outil de langage «de base» pour cela.

La solution à cette situation est la vente au niveau git. Vous avez votre propre référentiel git (je l'appelle « destination repo »), et vous souhaitez incorporer un autre référentiel (je l'appelle « source repo ») en tant que répertoire dans votre (destination repo).

Les choses que vous attendez d'un système de vente bien conçu (peu importe Git ou non):

Visibilité Vous voulez savoir qu'un certain code est vendu, cela signifie qu'il n'a pas été écrit par committer.
Provenance Vous voulez savoir d'où cela vient. Quel était le référentiel que quelqu'un avait intégré à votre référentiel il y a deux ans? Et quelle version / commit était?
Mise à jour Vous voulez pouvoir mettre à jour ce code quand il corrige un bug dans le référentiel d'origine (ou a une nouvelle fonctionnalité attendue depuis longtemps). Comme cas particulier pour la mise à jour, vous voulez pouvoir supprimer le code commercial (et seulement lui).
Répétabilité La vente ne devrait pas être l'art, elle devrait être le processus rigide à l'abri des erreurs. le vendeur foo dans la barre devrait donner le même résultat, peu importe qui l'a fait.
Transportabilité. Une personne qui clonera votre référentiel devrait pouvoir continuer à gérer la commercialisation exactement de la même manière que vous. Cela signifie que toutes les informations liées au fournisseur doivent rester dans le git et être transférées pendant le push / pull.
Gouvernance. Toutes les modifications apportées par le fournisseur doivent rester «telles quelles» jusqu'à ce que quelqu'un les mette à jour. De plus, vous ne voulez pas avoir de mises à jour inattendues (cassées), vous voulez absolument garder les choses vendues disponibles même si le dépôt source n'est plus disponible.
Patchachabilité. Vous voulez pouvoir modifier le code du fournisseur et toujours le mettre à jour vers une version plus récente. De préférence, sans conflits, mais au moins, avec une visibilité claire où ces conflits se sont produits.

Et, étant donné la nature git de Git, vous voulez que ce système soit compatible avec les succursales. Si la branche A a du code fournisseur à la version a1 et la branche B à la version b1, vous souhaitez basculer entre elles chaque fois que vous basculez entre A et B. De plus, vous voulez pouvoir changer la version a1 en a2 et la version b1 en b2 sans se soucier des versions dans une autre branche.

... Et vous voulez pouvoir vendre plus d'un référentiel externe, donc la vente ne doit pas être un événement unique par repo.

Comme vous pouvez le voir, c'est une longue liste d'exigences. J'ai analysé les (autres) solutions existantes avant d'arriver à la meilleure solution (git vendor).

Copier coller

Le copier-coller est un moyen si vicieux de vendre n'importe quoi que je n'ai rien de bon à dire à ce sujet. Vous perdez la provenance, la visibilité, la possibilité de mise à jour. Vous ne perdez pas la transportabilité, car il n'y a pas de lien avec l'ancien dépôt en premier lieu. Ne faites pas de vente comme ça.

Git-in-git

C'est une astuce stupide mais quelque peu efficace. Créez un dossier vendored_foobar dans votre référentiel, allez dans vendored_foobar et clonez cette foobar. Revenez au niveau supérieur et validez toutes les modifications que vous avez.

Avantages: simple à faire, fournit une provenance locale, une bonne gouvernance et une excellente patchablité.

Inconvénients: il est fragile, il ne survit pas à la poussée (le dossier .git imbriqué n'est pas inclus dans votre référentiel, donc pour les observateurs externes, le code fourni par le vendeur est impossible à distinguer du vôtre). Vous perdrez donc la transportabilité et la provenance à long terme.

Sous-modules

L'idée est que vous avez certains dossiers de votre git gérés dans un autre git. C'est le plus ancien `` quelque chose '' que git avait fourni. Malheureusement, il n'est pas favorable aux succursales et il manque de gouvernance sur le code commercial. Si le dépôt à distance a disparu, vous ne pouvez pas utiliser vos sous-modules.

Et n'oubliez pas combien il est difficile de cloner ce dépôt.

sous-arbre git

Git peut utiliser la méthode 'subtree' pour fusionner des gits externes en tant que dossiers dans le référentiel git local. Il est presque parfait, à l'exception de la mise à jour, de la répétabilité, de la provenance et de la visibilité. À moins que le manuel ne fouille dans une histoire git, il est impossible de voir quelle partie du dépôt git est vendue et laquelle ne l'est pas. Et vous ne savez pas d'où viennent ces changements. Si committer n'a pas écrit cela, les informations sont perdues. Et si c'est le cas, ce n'est pas reproductible car des changements mineurs peuvent se produire lors du remplissage de ces informations.

Alors, entrez le gagnant prisé, git vendor.

Vendeur Git

Git vendor est une extension étonnante pour git écrite par Brett Langdon il y a environ trois ans. C'est juste environ 200 lignes en bash, mais c'est tellement bien écrit que je ne m'en plains pas du tout (il a tout ce qu'un bon programme devrait avoir: pages de manuel, aide, achèvement de bash, gestion raisonnable des erreurs et protections de sécurité).

Il utilise git subtree et l'étend avec des fonctions pour couvrir les côtés lâches de la vente par git subtree.

Chaque point important est vérifié:

visibilité. Appelez simplement la git vendor list et voyez toutes les choses vendues.
provenance. Il montre le dépôt à distance et permet de voir quel commit a été vendu.
possibilité de mise à jour. git vendor update , et il prend en charge les branches, les balises et les commits comme un moyen de déterminer exactement ce qu'il faut prendre. Et vous pouvez bien sûr git vendor remove .
répétabilité. Il n'y a aucune opération manuelle impliquée, donc tout le monde obtiendra le même résultat lors de la première livraison ou des mises à jour suivantes.
transportabilité. Toutes les modifications sont stockées sous forme de balises spéciales dans l'historique git, elles sont donc entièrement compatibles push / pull. Et ils fonctionnent très bien avec les succursales et les retraits d'historique arbitraires.
govenrance. Tout le code commercial est stocké dans votre référentiel.
patchachabilité. C'est le cas (vous verrez une fusion claire des conflits avec vos modifications), mais c'est le côté le plus faible de git vendor. Je préférerais avoir une 'file d'attente de correctifs' (comme dans debian / pathes pour les paquets deb), mais néanmoins, il y a un support minimal pour cela.

Il a une politique spécifique sur la façon dont les choses sont vendues: si vous voulez cloner https://github.com/serverscom/dibctl il va dans vendor/github.com/serverscom/dibctl/ . Vous pouvez changer la partie ' vendor/ ', mais le reste est une politique difficile. Les liens symboliques peuvent cependant faciliter cela.

Il y a quelques bugs mineurs: vous ne pouvez pas l'utiliser sur des dépôts vides, vous ne pouvez pas utiliser les gits locaux comme sources, vous ne pouvez pas voir d'aide tant que vous n'êtes pas dans git repo. Aucun d'entre eux ne pose de problèmes lors d'un travail normal avec de vrais repos.

Conclusion

git-vendor est un outil parfait pour vendre un dépôt git dans un autre. Il fournit toutes les fonctionnalités requises pour les meilleures pratiques de vente: conserver la provenance, assurer la visibilité et la mise à jour.

Comment vendre un git dans un autre git