Synopsis
git pack-objects [--stdout] [--all] <base-name> < <object-list>Description
The git pack-objects command compresses a set of objects into a single packfile, applying delta compression to similar objects. Packs are how Git stores objects efficiently on disk and over the network — every fetch and push transfers packs.
Dans l'usage quotidien, git pack-objects s'intègre étroitement avec les alias de shell, les plugins d'éditeur et l'intégration continue. Les utilisateurs avancés ajoutent souvent des alias combinant les flags qu'ils passent toujours, ou enveloppent la commande dans des scripts qui appliquent les conventions d'équipe. Le formatage de la sortie peut être personnalisé via la configuration Git — pretty formats, schémas de couleurs et comportement du pager sont tous ajustables. Quand quelque chose tourne mal, la première étape de diagnostic est généralement de relancer la commande avec GIT_TRACE=1 dans l'environnement, ce qui révèle les appels de plomberie sous-jacents. Pour les situations inhabituelles, la sortie --help (git pack-objects --help) ouvre la page de manuel complète avec les détails de chaque option, y compris celles rarement utilisées dans les workflows ordinaires mais essentielles pour le débogage ou le scripting à grande échelle.
Comprendre comment git pack-objects interagit avec le reste du modèle de données de Git — la base d'objets, l'index, les refs et l'arborescence de travail — est rentable. Chaque commande opère sur un sous-ensemble de ces pièces, et savoir laquelle elle touche aide à prédire les résultats et récupérer après les erreurs. Lire la documentation officielle de Git en parallèle de la pratique sur un dépôt jetable est la façon la plus rapide d'intérioriser les subtilités. La plupart des problèmes de production avec Git proviennent de l'une de trois causes : comportement par défaut surprenant, opérations réseau partielles, ou réécriture d'historique déjà partagé. Un modèle mental fonctionnel des effets de bord de git pack-objects aide à éviter les trois.
When to Use
You almost never invoke this directly. git gc, git repack, and the network protocol drive it for you. Reach for it manually when implementing custom transport, optimizing storage, or experimenting with delta strategies.
Options courantes
| Option | Description |
|---|---|
--stdout | Write the pack to stdout instead of files. |
--all | Pack everything reachable from any ref. |
--revs | Read revisions from stdin instead of object SHAs. |
--depth=<n> | Maximum delta chain depth. |
--window=<n> | Window size for delta search. |
--thin | Allow thin packs (deltas against external objects). |
--no-reuse-delta | Recompute deltas instead of reusing existing. |
Exemples
git rev-list --objects --all | git pack-objects --stdout > everything.pack
# Build a single pack of every reachable object
git rev-list --objects HEAD ^origin/main | \
git pack-objects --thin --stdout > ahead.pack
# A thin pack of just the commits ahead of origin/main
git pack-objects --all .git/objects/pack/extra
# Repack all reachable objects into a new pack named "extra"Erreurs fréquentes
Building large packs with --depth and --window set too high consumes lots of memory and CPU. The defaults from git gc are sensible for most repos. Producing thin packs without context (an existing repo to apply them to) is useless.
Commandes liées
git unpack-objects, git verify-pack, git gc, git repack