git-bundle - Déplace les objets et les références par archive

Créer, décompresser et manipuler des fichiers "bundle". Les colis sont utilisés pour le transfert "hors ligne" d’objets Git sans qu’un "serveur" actif se trouve de l’autre côté de la connexion réseau.

Ils peuvent être utilisés pour créer des sauvegardes incrémentielles et complètes d’un dépôt, et pour relayer l’état des références d’un dépôt à un autre.

Les commandes Git qui récupèrent ou autrement "lisent" via des protocoles tels que ssh:// et https:// peuvent aussi opérer sur des fichiers cois. Il est possible de git-clone[1] un nouveau dépôt à partir d’un colis, d’utiliser git-fetch[1] pour en récupérer, et de lister les références qu’il contient avec git-ls-remote[1]. Il n’y a pas de support d'"écriture" correspondant, c’est-à-dire qu’un git push dans un colis n’est pas supporté.

Voir la section "EXEMPLES" ci-dessous pour plus des exemples d’utilisation des colis.

Les colis sont des fichiers .pack (voir git-pack-objects[1]) avec un en-tête indiquant quelles références sont contenues dans le colis.

Comme le format d’archive packed lui-même, les colis peuvent être soit autonomes, soit créés à l’aide d’exclusions. Voir la section "PRÉREQUIS D’OBJET" ci-dessous.

Les colis créés en utilisant les exclusions de révision sont des "paquets minces" créés en utilisant l’option --thin de git-pack-objects[1], et dépaquetés en utilisant l’option --fix-thin de git-index-pack[1].

Il n’y a pas d’option pour créer un "paquet épais" lors de l’utilisation des exclusions de révision, et les utilisateurs ne doivent pas s’inquiéter de la différence. En utilisant des "paquets minces", les paquets créés à l’aide d’exclusions sont plus petits en taille. Le fait qu’ils soient "minces" sous le capot est simplement noté ici comme une curiosité, et comme une référence à d’autres documents.

Voir gitformat-bundle[5] pour plus de détails et la discussion sur le "paquets fins" dans gitformat-pack[5] pour plus de détails.

Les révisions doivent être accompagnées de noms de référence pour être regroupées dans un colis.

Plus d’une référence peut être empaquetée, et plus d’un ensemble d’objets prérequis peut être spécifié. Les objets empaquetés sont ceux qui ne sont pas contenus dans l’union des prérequis.

La commande git bundle create résout les noms de référence pour vous en utilisant les mêmes règles que git rev-parse --abbrev-ref=loose. Chaque pré-requis peut être spécifié explicitement (par exemple ^master~10), ou implicitement (par exemple master~10..master, --since=10.days.ago master).

Tous ces cas simples sont OK (en supposant que nous avons des branches "master" et "next") :

Et il en est de même pour ces exemples (et le même mais avec --stdin omis) :

Un nom de révision ou un intervalle dont le côté droit ne peut être résolu en une référence n’est pas accepté :

Lors de la création de colis, il est possible de créer un colis autonome qui peut être dégroupé dans un dépôt sans historique commun, ainsi que de fournir des révisions négatives pour exclure les objets nécessaires dans les parties antérieures de l’historique.

Fournir une révision telle que nouveau à git bundle create créera un fichier colis qui contient tous les objets accessibles depuis la révision nouveau. Ce colis peut être dégroupé dans n’importe quel dépôt pour obtenir un historique complet qui mène à la révision nouveau :

Une plage de révision telle que ancien..nouveau produira un fichier colis qui nécessitera l’existence de la révision ancien (et de tout objet pouvant être atteint à partir de celle-ci) pour que le colis puisse être "dégroupé" :

Un colis autonome sans pré-requis peut être extrait n’importe où, même dans un dépôt vide, ou peut être cloné (c-à-d, nouveau, mais pas ancien..nouveau).

Il n’y a pas de problème à être prudent et faire en sorte que le fichier regroupement contienne des objets déjà présents dans la destination, car ceux-ci sont ignorés lors du déballage à la destination.

Si vous voulez imiter git clone --mirror, qui inclurait vos refs comme refs/remotes/*, utilisez --all. Si vous voulez fournir le même ensemble de références qu’un clone directement depuis le dépôt source, utilisez --branches --tags pour les <arguments-git-rev-list>.

La commande git bundle verify peut être utilisée pour vérifier si votre dépôt destinataire possède les commits pré-requis nécessaires pour un colis.

Supposons que vous vouliez transférer l’historique d’un dépôt R1 sur la machine A vers un autre dépôt R2 sur la machine B. Pour une raison quelconque, la connexion directe entre A et B n’est pas autorisée, mais nous pouvons déplacer les données de A à B via un mécanisme quelconque (CD, email, etc.). Nous voulons mettre à jour R2 avec le développement fait sur la branche master dans R1.

Pour amorcer le processus, vous pouvez d’abord créer un paquet qui n’a pas de prérequis. Vous pouvez utiliser une étiquette pour vous rappeler jusqu’à quel commit le dernier traitement a été fait, afin de faciliter la mise à jour ultérieure de l’autre dépôt avec un paquet incrémental :

Ensuite, vous transférez fichier.paquet sur la machine cible B. Comme ce paquet ne nécessite pas l’extraction d’un objet existant, vous pouvez créer un nouveau déôt sur la machine B en le clonant :

Cela définira un répertoire distant appelé "origin" dans le dépôt résultant qui vous permettra de récupérer et de tirer du paquet. Le fichier $GIT_DIR/config dans R2 aura une entrée comme celle-ci :

Pour mettre à jour le dépôt mine.git résultant, vous pouvez récupérer ou tirer après avoir remplacé le paquet stocké dans /home/moi/tmp/fichier.paquet par des mises à jour incrémentales.

Après avoir travaillé un peu plus dans le dépôt d’origine, vous pouvez créer un paquet incrémental pour mettre à jour l’autre dépôt :

Vous transférez ensuite le paquet sur l’autre machine pour remplacer /home/moi/tmp/fichier.paquet, et vous tirez à partir de celui-ci.

Si vous savez jusqu’à quel commit le dépôt destinataire devrait avoir les objets nécessaires, vous pouvez utiliser cette connaissance pour spécifier le prérequis, en donnant un point de coupure pour limiter les révisions et les objets qui vont dans le paquet résultant. L’exemple précédent a utilisé l’étiquette dernierpaquetR2 dans ce but, mais vous pouvez utiliser toute autre option que vous donneriez à la commande git-log[1]. Voici d’autres exemples :

Vous pouvez utiliser une étiquette qui est présente dans les deux dépôts :

Vous pouvez utiliser un prérequis défini par le temps :

Vous pouvez utiliser le nombre de commits :

Vous pouvez lancer git-bundle verify pour voir si vous pouvez extraire d’un paquet qui a été créé avec un prérequis :

Cela permettra d’énumérer ce que vous devez avoir pour extraire du paquet et fera une erreur si vous ne les avez pas.

Du point de vue du dépôt destinataire, un paquet est exactement comme un dépôt ordinaire dont il extrait ou tire des données. Vous pouvez, par exemple, aligner les références lors de l’extraction :

Vous pouvez également voir quelles références il offre :

Voir gitformat-bundle[5].

Fait partie de la suite git[1]

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .