7.12 Utilitaires Git - Empaquetage (bundling)

Bien que nous ayons déjà abordé les méthodes les plus communes de transfert de données Git par réseau (HTTP, SSH, etc.), il existe en fait une méthode supplémentaire qui n’est pas beaucoup utilisée mais qui peut s’avérer utile.

Git est capable d’empaqueter ses données dans un fichier unique. Ceci peut servir dans de nombreux scénarios. Le réseau peut être en panne et vous souhaitez envoyer des modifications à vos collègues. Peut-être êtes-vous en train de travailler à distance et vous ne pouvez pas vous connecter au réseau local pour des raisons de sécurité. Peut-être que votre carte réseau ou votre carte wifi vient de tomber en panne. Peut-être encore n’avez-vous pas accès à un serveur partagé, et vous souhaitez envoyer à quelqu’un des mises à jour sans devoir transférer 40 commits via format-patch.

Ce sont des situations où la commande git bundle est utile. La commande bundle va empaqueter tout ce qui serait normalement poussé sur le réseau avec une commande git push dans un fichier binaire qui peut être envoyé à quelqu’un par courriel ou copié sur une clé USB, puis de le dépaqueter dans un autre dépôt.

Voyons un exemple simple. Supposons que vous avez un dépôt avec deux commits :

Si vous souhaitez envoyer ce dépôt à quelqu’un et que vous n’avez pas accès en poussée à un dépôt, ou que simplement vous ne voulez pas en créer un, vous pouvez l’empaqueter avec git bundle create.

À présent, vous avez un fichier repo.bundle qui contient toutes les données nécessaires pour recréer la branche master du dépôt. Avec la commande bundle, vous devez lister toutes les références ou les intervalles spécifiques de commits que vous voulez inclure. Si vous le destinez à être cloné ailleurs, vous devriez aussi ajouter HEAD comme référence, comme nous l’avons fait.

Vous pouvez envoyer ce fichier repo.bundle par courriel, ou le copier sur une clé USB et la tendre à un collègue.

De l’autre côté, supposons qu’on vous a envoyé ce fichier repo.bundle et que vous voulez travailler sur le projet. Vous pouvez cloner le fichier binaire dans un répertoire, de la même manière que vous le feriez pour une URL.

Si vous n’incluez pas HEAD dans les références, vous devez aussi spécifier -b master ou n’importe quelle branche incluse dans le paquet car sinon, il ne saura pas quelle branche extraire.

Maintenant, supposons que vous faites 3 commits et que vous voulez renvoyer ces nouveaux commits via courriel ou clé USB.

Nous devons déjà déterminer l’intervalle de commits que nous voulons inclure dans le colis. À la différence des protocoles réseau qui calculent automatiquement l’ensemble minimum des données à transférer, nous allons devoir les définir manuellement. Ici, vous pourriez tout à fait lancer la même commande et empaqueter le dépôt complet, ce qui marcherait mais c’est mieux de n’empaqueter que la différence ‑ seulement les 3 commits que nous avons localement créés.

Pour le faire, vous allez devoir calculer la différence. Comme décrit dans Plages de commits, vous pouvez faire référence à un intervalle de commits de différentes manières. Pour désigner les trois commits que nous avons dans notre branche master et qui n’était pas dans la branche que nous avons initialement clonée, nous pouvons utiliser quelque chose comme origin/master..master ou master ^origin/master. Vous pouvez tester cela avec la sortie de la commande log.

Comme nous avons maintenant la liste des commits que nous voulons inclure dans le colis, empaquetons-les. Cela est réalisé avec la commande git bundle create, suivie d’un nom de fichier et des intervalles des commits que nous souhaitons inclure.

Nous avons à présent un fichier commits.bundle dans notre répertoire. Si nous le prenons et l’envoyons à un partenaire, il pourra l’importer dans le dépôt d’origine, même si du travail a été ajouté entre temps.

Quand il récupère le colis, il peut l’inspecter pour voir ce qu’il contient avant de l’importer dans son dépôt. La première commande est bundle verify qui va s’assurer que le fichier est une fichier bundle Git valide et que le dépôt contient tous les ancêtres nécessaires pour appliquer correctement le colis.

Si la personne avait créé un colis ne contenant que les deux derniers commits qu’il avait ajoutés, plutôt que les trois, le dépôt initial n’aurait pas pu l’importer, car il aurait manqué un commit dans l’historique à reconstituer. La commande verify aurait ressemblé plutôt à ceci :

Cependant, notre premier colis est valide, et nous pouvons récupérer des commits depuis celui-ci. Si vous souhaitez voir les branches présentes dans le colis qui peuvent être importées, il y a aussi une commande pour donner la liste des sommets des branches :

La sous-commande verify vous indiquera aussi les sommets. L’objectif est de voir ce qui peut être tiré, pour que vous puissiez utiliser les commandes fetch et pull pour importer des commits depuis le colis. Ici, nous allons récupérer la branche master du colis dans une branche appelée other-master dans notre dépôt :

Maintenant, nous pouvons voir que nous avons importé les commits sur la branche other-master ainsi que tous les commits que nous avons validés entre-temps dans notre propre branche master.

Ainsi, git bundle peut vraiment être utile pour partager du code ou réaliser des opérations nécessitant du réseau quand il n’y a pas de réseau ou de dépôt partagé.