Git
Français ▾ Topics ▾ Latest version ▾ git-bundle last updated in 2.34.1

NOM

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

SYNOPSIS

git bundle create [-q | --quiet | --progress | --all-progress] [--all-progress-implied]
		    [--version=<version>] <fichier> <arguments-git-rev-list>
git bundle verify [-q | --quiet] <fichier>
git bundle list-heads <fichier> [<nom-de-ref>…​]
git bundle unbundle [--progress] <fichier> [<nom-de-ref>…​]

DESCRIPTION

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.

FORMATS 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].

There is no option to create a "thick pack" when using revision exclusions, and users should not be concerned about the difference. By using "thin packs", bundles created using exclusions are smaller in size. That they’re "thin" under the hood is merely noted here as a curiosity, and as a reference to other documentation.

See the bundle-format documentation for more details and the discussion of "thin pack" in the pack format documentation for further details.

OPTIONS

create [options] <fichier> <git-rev-list-args>

Utilisé pour créer un regroupement nommé fichier. Cela nécessite les arguments <arguments-git-rev-list> pour définir le contenu du regroupement. options' contient les options spécifiques à la sous-commande git bundle create.

verify <fichier>

Utilisé pour vérifier qu’un fichier regroupement est valide et s’appliquera proprement au dépôt actuel. Cela inclut des vérifications sur le format du regroupement lui-même ainsi que la vérification que les commits pré-requis existent et sont complètement liés dans le dépôt actuel. git bundle affiche une liste des commits manquants, s’il y en a, et sort avec un statut non nul.

list-heads <fichier>

Liste les références définies dans le regroupement. Si elle est suivie d’une liste de références, seules les références correspondant à celles données sont imprimées.

unbundle <fichier>

Passe les objets du groupement à git index-pack pour qu’ils soient stockés dans le dépôt, puis affiche les noms de toutes les références définies. Si une liste de références est donnée, seules les références correspondant à celles de la liste sont imprimées. Cette commande est vraiment de plomberie et n’est définie que pour être appelée par git fetch.

<git-rev-list-args>

Une liste d’arguments, acceptable pour git rev-parse et git rev-list (et contenant une référence nommée, voir SPECIFICATION DES REFERENCES ci-dessous), qui spécifie les objets et références spécifiques à transporter. Par exemple, master~10..master fait en sorte que la référence master actuelle soit regroupée avec tous les objets ajoutés depuis le dixième commit de son ancêtre. Il n’y a pas de limite explicite au nombre de références et d’objets qui peuvent être regroupés.

[<nom-de-réf>…​]

Une liste de références utilisée pour limiter les références signalées comme disponibles. Ceci est principalement utile à git fetch, qui s’attend à ne recevoir que les références demandées et pas nécessairement tout le contenu du pack (dans ce cas, git bundle agit comme git fetch-pack).

--progress

L’état d’avancement est affiché sur la sortie d’erreur standard quand elle est attachée à un terminal, à moins que -q soit spécifié. Ce drapeau force l’état d’avancement même si le flux d’erreur standard n’est pas dirigé vers un terminal.

--all-progress

Lorsque --stdout est spécifié, le rapport de progression est affiché pendant les phases de comptage d’objets et de compression, mais il est inhibé pendant la phase d’écriture. La raison en est que dans certains cas, le flux de sortie est directement lié à une autre commande qui peut souhaiter afficher son propre état d’avancement pendant qu’elle traite les données du paquet entrant. Ce drapeau est comme --progress sauf qu’il force le rapport de progression pour la phase d’écriture même si --stdout est utilisé.

--all-progress-implied

C’est utilisé pour impliquer --all-progress lorsque l’affichage de la progression est activé. Contrairement à --all-progress, ce drapeau ne force pas l’affichage de la progression par lui-même.

--version[=<version>]

Spécifier la version du regroupement. La version 2 est l’ancien format et ne peut être utilisée qu’avec les dépôts SHA-1 ; la version 3, plus récente, contient des capacités qui permettent des extensions. La valeur par défaut est le plus ancien format pris en charge, en fonction de l’algorithme de hachage utilisé.

-q
--quiet

Ce drapeau permet à la commande de ne pas signaler sa progression sur le flux d’erreur standard.

SPÉCIFICATION DES RÉFÉRENCES

Revisions must be accompanied by reference names to be packaged in a bundle.

More than one reference may be packaged, and more than one set of prerequisite objects can be specified. The objects packaged are those not contained in the union of the prerequisites.

The git bundle create command resolves the reference names for you using the same rules as git rev-parse --abbrev-ref=loose. Each prerequisite can be specified explicitly (e.g. ^master~10), or implicitly (e.g. master~10..master, --since=10.days.ago master).

All of these simple cases are OK (assuming we have a "master" and "next" branch):

$ git bundle create master.bundle master
$ echo master | git bundle create master.bundle --stdin
$ git bundle create master-and-next.bundle master next
$ (echo master; echo next) | git bundle create master-and-next.bundle --stdin

And so are these (and the same but omitted --stdin examples):

$ git bundle create recent-master.bundle master~10..master
$ git bundle create recent-updates.bundle master~10..master next~5..next

A revision name or a range whose right-hand-side cannot be resolved to a reference is not accepted:

$ git bundle create HEAD.bundle $(git rev-parse HEAD)
fatal: Refusing to create empty bundle.
$ git bundle create master-yesterday.bundle master~10..master~5
fatal: Refusing to create empty bundle.

OBJECT PREREQUISITES

When creating bundles it is possible to create a self-contained bundle that can be unbundled in a repository with no common history, as well as providing negative revisions to exclude objects needed in the earlier parts of the history.

Feeding a revision such as new to git bundle create will create a bundle file that contains all the objects reachable from the revision new. That bundle can be unbundled in any repository to obtain a full history that leads to the revision new:

$ git bundle create complet.bundle nouveau

A revision range such as old..new will produce a bundle file that will require the revision old (and any objects reachable from it) to exist for the bundle to be "unbundle"-able:

$ git bundle create complet.bundle ancien..nouveau

A self-contained bundle without any prerequisites can be extracted into anywhere, even into an empty repository, or be cloned from (i.e., new, but not old..new).

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>.

The git bundle verify command can be used to check whether your recipient repository has the required prerequisite commits for a bundle.

EXEMPLES

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 :

machineA$ cd R1
machineA$ git bundle create fichier.paquet master
machineA$ git tag -f dernierpaquetR2 master

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 :

machineB$ git clone -b master /home/moi/tmp/fichier.paquet R2

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 :

[remote "origin"]
    url = /home/moi/tmp/fichier.paquet
    fetch = refs/heads/*:refs/remotes/origin/*

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 :

machineA$ cd R1
machineA$ git bundle create fichier.paquetdernierpaquetR2..master
machineA$ git tag -f dernierpaquetR2 master

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

machineB$ cd R2
machineB$ git pull

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 :

$ git bundle create monpaquet v1.0.0..master

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

$ git bundle create monpaquet --since=10.days master

Vous pouvez utiliser le nombre de commits :

$ git bundle create monpaquet -10 master

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

$ git bundle verify monpaquet

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 :

$ git fetch monpaquet master:localRef

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

$ git ls-remote monpaquet

GIT

Fait partie de la suite git[1]

TRADUCTION

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 .

scroll-to-top