Git bundle как пользоваться

7.12 Инструменты Git — Создание пакетов

Помимо рассмотренных ранее основных способов передачи данных Git по сети (HTTP, SSH и т. п.), существует ещё один способ, который обычно не используется, но в некоторых случаях может быть весьма полезным.

Git умеет «упаковывать» свои данные в один файл. Это может быть полезным в разных ситуациях. Может быть, ваша сеть не работает, а вы хотите отправить изменения своим коллегам. Возможно, вы работаете откуда-то извне офиса и не имеете доступа к локальной сети по соображениям безопасности. Может быть, ваша карта беспроводной/проводной связи просто сломалась. Возможно, у вас в данный момент нет доступа к общему серверу, а вы хотите отправить кому-нибудь по электронной почте обновления, но передавать 40 коммитов с помощью format-patch не хотите.

В этих случаях вам может помочь команда git bundle . Она упакует всё, что в обычной ситуации было бы отправлено по сети командой git push , в бинарный файл, который вы можете передать кому-нибудь по электронной почте или поместить на флешку и затем распаковать в другом репозитории.

Рассмотрим простой пример. Допустим, у вас есть репозиторий с двумя коммитами:

$ git log commit 9a466c572fe88b195efd356c3f2bbeccdb504102 Author: Scott Chacon Date: Wed Mar 10 07:34:10 2010 -0800 Second commit commit b1ec3248f39900d2a406049d762aa68e9641be25 Author: Scott Chacon Date: Wed Mar 10 07:34:01 2010 -0800 First commit

Если вы хотите отправить кому-нибудь этот репозиторий, но не имеете доступа на запись к общей копии репозитория или просто не хотите его настраивать, то вы можете упаковать его командой git bundle create .

$ git bundle create repo.bundle HEAD master Counting objects: 6, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (6/6), 441 bytes, done. Total 6 (delta 0), reused 0 (delta 0)

В результате вы получили файл repo.bundle , в котором содержатся все данные, необходимые для воссоздания ветки master репозитория. Команде bundle необходимо передать список или диапазон коммитов, которые вы хотите добавить в пакет. Если вы намереваетесь использовать пакет для того, чтобы клонировать репозиторий где-нибудь ещё, вы должны добавить в этот список HEAD, как это сделали мы.

Вы можете отправить файл repo.bundle кому-нибудь по электронной почте или скопировать его на USB-диск, тем самым легко решив исходную проблему.

С другой стороны, допустим, вы получили файл repo.bundle и хотите поработать над этим проектом. Вы можете клонировать репозиторий из бинарного файла в каталог, почти также как вы делаете это при использовании URL.

$ git clone repo.bundle repo Cloning into 'repo'. . $ cd repo $ git log --oneline 9a466c5 Second commit b1ec324 First commit

Если при создании пакета вы не указали в списке ссылок HEAD, то при распаковке вам потребуется указать -b master или какую-либо другую ветку, включённую в пакет, иначе Git не будет знать, на какую ветку ему следует переключиться.

Теперь предположим, что вы сделали три коммита и хотите отправить их обратно в виде пакета на USB-флешке или по электронной почте.

$ git log --oneline 71b84da Last commit - second repo c99cf5b Fourth commit - second repo 7011d3d Third commit - second repo 9a466c5 Second commit b1ec324 First commit

Во-первых, нам нужно определить диапазон коммитов, которые мы хотим включить в пакет. В отличие от сетевых протоколов, которые сами выясняют минимальный набор данных, который нужно передать по сети, в данном случае мы должны сделать это сами вручную. В данном примере вы можете сделать, как раньше и упаковать полностью весь репозиторий, но будет лучше упаковать только изменения — три коммита, сделанные локально.

Для того, чтобы сделать это, вы должны вычислить различия. Как мы рассказывали в Диапазоны коммитов, вы можете указать диапазон коммитов несколькими способами. Для того, чтобы получить три коммита из нашей основной ветки, которые отсутствовали в изначально клонированной ветке, мы можем использовать запись вида origin/master..master или master ^origin/master . Вы можете проверить её с помощью команды log .

$ git log --oneline master ^origin/master 71b84da Last commit - second repo c99cf5b Fourth commit - second repo 7011d3d Third commit - second repo

Так что теперь у нас есть список коммитов, которые мы хотим включить в пакет, давайте упакуем их. Сделаем мы это с помощью команды git bundle create , указав имя выходного пакета и диапазон коммитов, которые мы хотим включить в него.

$ git bundle create commits.bundle master ^9a466c5 Counting objects: 11, done. Delta compression using up to 2 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (9/9), 775 bytes, done. Total 9 (delta 0), reused 0 (delta 0)

В результате в нашем каталоге появился файл commits.bundle . Если мы отправим его нашему коллеге, то он сможет импортировать пакет в исходный репозиторий, даже если в репозитории была проделана некоторая работа параллельно с нашей.

При получении пакета коллега перед импортом его в свой репозиторий может проверить пакет, просмотрев его содержимое. Лучшей командой для этого является bundle verify , которая может проверить, что файл действительно является корректным Git-пакетом и что у вас есть все необходимые предки коммитов для правильного его восстановления.

$ git bundle verify ../commits.bundle The bundle contains 1 ref 71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master The bundle requires these 1 ref 9a466c572fe88b195efd356c3f2bbeccdb504102 second commit ../commits.bundle is okay

Если автор создал пакет только с последними двумя коммитами, которые он сделал, а не со всеми тремя, то исходный репозиторий не сможет импортировать этот пакет, так как у него отсутствует необходимая история. В таком случае команда verify вернёт нечто подобное:

$ git bundle verify ../commits-bad.bundle error: Repository lacks these prerequisite commits: error: 7011d3d8fc200abe0ad561c011c3852a4b7bbe95 Third commit - second repo

Однако, наш первый пакет корректен, поэтому мы можем извлечь коммиты из него. На случай если вы захотите увидеть ветки пакета, которые могут быть импортированы, существует команда для отображения только списка веток:

$ git bundle list-heads ../commits.bundle 71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master

Подкоманда verify также выводит список веток. Если цель состоит в том, чтобы увидеть, что может быть извлечено из пакета, то вы можете использовать команды fetch или pull для импорта коммитов. Ниже мы ветку master из пакета извлекаем в ветку other-master нашего репозитория:

$ git fetch ../commits.bundle master:other-master From ../commits.bundle * [new branch] master -> other-master

Теперь мы можем увидеть, какие коммиты мы импортировали в ветку other-master так же, как и любые коммиты, которые мы сделали в то же время в нашей собственной ветке master .

$ git log --oneline --decorate --graph --all * 8255d41 (HEAD, master) Third commit - first repo | * 71b84da (other-master) Last commit - second repo | * c99cf5b Fourth commit - second repo | * 7011d3d Third commit - second repo |/ * 9a466c5 Second commit * b1ec324 First commit

Таким образом, команда git bundle может быть, действительно, полезной для организации совместной работы или для выполнения сетевых операций, когда у вас нет доступа к соответствующей сети или общему репозиторию.

MrDekk

Время — лучший учитель! Жаль, что оно убивает своих учеников.

© 2019. All rights reserved.

Передача веток и коммитов между двумя GIT-репозиториями

Случилась такая задача. Есть два git-репозитория (один из которых ко всему прочему соединен с SVN через git-svn). Между ними необходимо передавать ветки и коммиты. Если бы они имели прямую связь через файловую систему или например через http, особых проблем бы не было. Однако, никакой связи кроме человека с флэшкой между этими репозиториями нет. Поэтому пришлось изобретать некий workflow который позволил бы эффективно эту проблему решить.

Вот картинка того, что требуется сделать:

Решить эту проблему можно тремя способами:

• Скопировать весь локальный репозиторий одной стороны (например, Repo A) и перенести его на флэшке рядом с репозиторием (Repo B) чтобы между ними можно было установить прямую связь через локальную файловую систему
• Использовать механизм патчей (git am)
• Использовать механизм пакетов git’а (git bundles)

Первый способ нам не подошел. Хотя бы потому, что репозиторий весит около 1.5 ГБ в сжатом виде. А заливать его приходилось в том числе через RDP соединение. Хотя если у вас есть такая возможность – это самый правильный и самый лучший вариант. Нам увы не подошел, поэтому идем дальше.

Второй способ мы даже активно использовали. Workflow там примерно следующий. С какого-то определенного коммита мы делаем набор патчей для каждого коммита выбранной ветки. На другом репозитории мы переключаемся (или создаем если такой ветки еще нет) на нужную ветку и делаем Apply Patch Serial. В принципе это все работает, но есть проблемы. Проблема первая – фактически в двух репозиториях мы имеем две разные ветки, хоть они одинаково и называются. И содержат разные коммиты, хоть и они содержат одно и то же. Кроме того, возникают нетривиальные вещи связанные с разрешением коллизий. Вообщем, достаточно громоздко и сложно, хотя и работает.

Третий способ – git bundles. Вот его и рассмотрим.

Начнем с того, что git bundle – это такой специальный файл. В который во-первых упакованы нужные ветки и нужные коммиты (вы их указываете сами). Во-вторых, он может представляться как удаленный git-репозиторий, который можно добавить в remotes и работать с ним как с полноценным удаленным репозиторием. Скажем так – этот подход – лайт версия первого подхода, когда вы тащите за собой весь репозиторий. Только здесь вы тащите один файл с тем, что надо. Места он правда может занять тоже весьма нехило, но в общем гораздо меньше (при правильном подходе), чем весь репозиторий.

Теперь давайте рассмотрим как это дело провернуть. Предположим у вас есть репозиторий A из которого необходимо перетащить ветку в репозиторий B (который пуст).

Имеем несколько файлов в репозитории A:

Создание бандлов

Теперь нам нужно создать (пересоздать) бандл. Тут два пути – если он уже был создан когда-то, или же его еще не было.

Случай, когда мы создаем новый бандл

# Создаем новый бандл для ветки мастер (веток может быть несколько) $ git bundle create ../master.bundle master # Помечаем последний коммит на ветке мастер который мы себе забрали (чтобы в следующий раз не тащить все) # lastR2bundle - просто некоторое имя $ git tag -f lastR2bundle master 

Случай, если бандл уже создавали (и появились новые изменения)

# Создаем бандл, но уже с указанием места, с которого его создавали в предыдущий раз $ git bundle create ../master2.bundle lastR2bundle..master # Обновляем указатель последнего коммита бандла $ git tag -f lastR2bundle master 

Разворачивание бандлов

Теперь бандл у нас есть, необходимо развернуть (обновить) его на другом репозитории RepoB.

В случае если бандл мы принесли первый раз и репозитория нет.

Тогда можно просто склонировать репозиторий прямо с бандла:

# Клонируем репозиторий с бандла в текущую папку $ git clone -b master C:/Temp/gittest/master.bundle . 

Ветка автоматически разворачивается до текущего состояния (флаг -b master указывает нужную ветку)

Случай, когда бандл принесли первый раз, но репозиторий уже есть

Тут несколько сложнее, необходимо зайти в папку .git в корне репозитория и отредактировать там файл config

# создаем новый remote с именем RepoA [remote "RepoA"] # указываем путь до бандла url = C:/Temp/gittest/master.bundle # указываем способ получения веток из бандла fetch = +refs/heads/*:refs/remotes/RepoA/* 

После этого делаем

$ git pull RepoA master 

И получаем выгруженную историю из бандла.

Случай, когда бандл уже приносили

В этом случае достаточно заменить старую версию бандла новым, и сделать git pull. Бандлы, сделанные не с самого «начала времен» а с определенного места занимают не так много места.

Надеюсь всем было все понятно и это поможет вам вести удобную разработку с использованием git’а.

P.S. Механизм бандлов работает в обе стороны, изменения в нашей схеме можно переносить не только из RepoA в RepoB, но и наоборот.

How to use git-bundle for keeping development in sync?

I need to keep my development trees in sync on different computers, with no network connection between them. We have a central git repository, and I normally work on my own clone on my office computer. Sometimes I need to do some development on another computer, which is never connected to the office network. None of the computers are ever connected to Internet. Development may be performed on both computers between synchronizations. I have read the help pages for git-bundle, which seems like the best tool, but I am not really sure how a good workflow could be set up. Can you give me some advice or pointers?

16.5k 4 4 gold badges 27 27 silver badges 27 27 bronze badges
asked Sep 3, 2010 at 12:59
28k 6 6 gold badges 38 38 silver badges 37 37 bronze badges

If they are connected to internet, you could use them with DopBox: see stackoverflow.com/questions/3632723/git-with-dropbox/…

Sep 3, 2010 at 14:11
Sorry, none of them will ever be connected to internet. Added that to the question.
Sep 3, 2010 at 14:21

2 Answers 2

Bundles!

The workflow with git bundle is going to be essentially the same as any other workflow. This may not seem like terribly helpful advice, but here it is: use whatever workflow you would normally use, and replace «push/pull» with «carry a bundle here to there on a flash drive, then pull».

The man page actually has a pretty good walkthrough for getting going with this, although it’s more of a one-way example. For the sake of completeness, here’s a slightly modified version of it, showing how to move information both ways:

# on hostA, the initial home of the repo hostA$ git bundle create hostA.bundle --branches --tags # transfer the bundle to hostB, and continue: hostB$ git clone /path/to/hostA.bundle my-repo # you now have a clone, complete with remote branches and tags # just to make it a little more obvious, rename the remote: hostB$ git remote rename origin hostA # make some commits on hostB; time to transfer back to hostA # use the known master branch of hostA as a basis hostB$ git bundle create hostB.bundle ^hostA/master --branches --tags # copy the bundle back over to hostA and continue: hostA$ git remote add hostB /path/to/hostB.bundle # fetch all the refs from the remote (creating remote branches like hostB/master) hostA$ git fetch hostB # pull from hostB's master, for example hostA$ git pull # make some commits on hostA; time to transfer to hostB # again, use the known master branch as a basis hostA$ git bundle create hostA.bundle ^hostB/master --branches --tags # copy the bundle to hostB, **replacing** the original bundle # update all the refs hostB$ git fetch hostA # and so on and so on 

The key thing to notice is that you can add a bundle as a remote, and interact with it just as you would with any other remote. To update that remote, just drop in a new bundle, replacing the previous one.

I’ve also taken a slightly different approach to picking a basis. The man page uses tags, always kept up to date with the last refs which were transferred to the other host. I’ve simply used the remote branches, which will refer to the last refs transferred from the other host. It’s a little bit inefficient; you’ll end up bundling more than you need to, since it’s one step behind. But flash drives are big, bundles are small, and using the refs you already have instead of having to take an extra step and be careful about tags saves a lot of effort.

The one thing that makes bundles a bit of trouble is that you can’t push to them, and you can’t «rebase» them. If you want the bundle based on a new basis, you have to recreate it. If you want new commits in it, you have to recreate it. This hassle gives rise to my next suggestion.

Repo on a thumb drive

Honestly, unless your repo is really big, this might be just as easy. Put a bare clone on a thumb drive, and you can push to and pull from it from both computers. Treat it like your network connection. Need to transfer to the central repo? Plug it in!

git-bundle

Создавайте, распаковывайте и манипулируйте «пакетными» файлами. Пакеты используются для «автономной» передачи объектов Git без активного «сервера», расположенного по другую сторону сетевого соединения.

Их можно использовать для создания как инкрементных, так и полных резервных копий репозитория, а также для передачи состояния ссылок в одном репозитории в другой.

Команды Git, которые извлекают или иным образом «читают» через такие протоколы, как ssh:// и https:// , также могут работать с пакетными файлами. Можно git-clone[1] создать новый репозиторий из пакета, использовать git-fetch[1] для извлечения из него и вывести список ссылок, содержащихся в нем, с помощью git-ls-remote[1] . Нет соответствующей поддержки записи, i.e.a git push в комплекте не поддерживается.

Примеры использования пакетов см. в разделе «EXAMPLES» ниже.

Bundle format

Пакеты представляют собой файлы .pack (см. git-pack-objects[1] ) с заголовком, указывающим, какие ссылки содержатся в пакете.

Как и сам формат упакованного архива, пакеты могут быть автономными или создаваться с использованием исключений. См. раздел «OBJECT PREREQUISITES» ниже.

Пакеты, созданные с использованием исключений версий, представляют собой «тонкие пакеты», созданные с использованием параметра —thin для git-pack-objects[1] и разделенные с помощью параметра —fix-thin для git-index-pack[1] .

При использовании исключений редакций нет возможности создать «толстый пакет», и пользователи не должны беспокоиться об этой разнице. При использовании «тонких пакетов» пакеты, созданные с использованием исключений, имеют меньший размер. То, что они «тонкие» под капотом, просто отмечено здесь как любопытство и как ссылка на другую документацию.

См. gitformat-bundle[5] для получения более подробной информации и обсуждение «тонкой упаковки» в gitformat-pack[5] для получения дополнительной информации.

Options

создать [опции]

Используется для создания пакета с именем file . Для этого требуются аргументы для определения содержимого пакета. options содержит параметры, относящиеся к подкоманде git bundle create . Если file — — , пакет записывается в стандартный вывод.

Используется для проверки того, что пакетный файл действителен и будет корректно применяться к текущему репозиторию. Это включает в себя проверку самого формата пакета, а также проверку наличия обязательных коммитов и их полной компоновки в текущем репозитории. Затем git bundle выводит список отсутствующих коммитов, если таковые имеются. Наконец, выводится информация о дополнительных возможностях, таких как «фильтр объектов». См. «Capabilities» в gitformat-bundle[5] для получения дополнительной информации. Код выхода равен нулю в случае успеха, но будет ненулевым, если пакетный файл недействителен. Если file — это — , пакет считывается со стандартного ввода.

Список ссылок, определенных в пакете. Если за ним следует список ссылок, распечатываются только те ссылки, которые соответствуют приведенным. Если file — это — , пакет считывается со стандартного ввода.

Передает объекты в пакете git index-pack для хранения в репозитории, затем печатает имена всех определенных ссылок. Если указан список ссылок, печатаются только те ссылки, которые соответствуют ссылкам в списке. Эта команда действительно сантехническая, предназначенная для вызова только git fetch . Если file — это — , пакет считывается со стандартного ввода.

Список аргументов, приемлемых для git rev-parse и git rev-list (и содержащий именованную ссылку, см. SPECIFYING REFERENCES below),, в которой указываются конкретные объекты и ссылки для переноса. Например, master~10..master вызывает упаковку текущей главной ссылки вместе со всеми объектами, добавленными с момента фиксации ее 10-го предка. Нет явного ограничения на количество ссылок и объектов, которые могут быть упакованы.

Список ссылок, используемый для ограничения ссылок, сообщаемых как доступные. Это в основном полезно для git fetch , который ожидает получить только те ссылки, которые запрошены, а не обязательно все в пакете (в этом случае git bundle действует как git fetch-pack ).

Состояние выполнения сообщается в стандартном потоке ошибок по умолчанию, когда он подключен к терминалу, если не указано -q. Этот флаг принудительно определяет состояние выполнения, даже если стандартный поток ошибок не направлен на терминал.

Укажите версию пакета. Версия 2 является более старым форматом и может использоваться только с репозиториями SHA-1; более новая версия 3 содержит возможности, допускающие расширения. По умолчанию используется самый старый поддерживаемый формат, основанный на используемом алгоритме хеширования.

Этот флаг заставляет команду не сообщать о своем прогрессе в стандартном потоке ошибок.

Specifying references

Редакции должны сопровождаться справочными именами, чтобы быть упакованными в пакет.

Можно упаковать более одной ссылки и указать более одного набора обязательных объектов. Упакованы объекты, не содержащиеся в объединении предварительных требований.

Команда git bundle create разрешает для вас ссылочные имена по тем же правилам, что и git rev-parse —abbrev-ref=loose . Каждое предварительное условие может быть указано явно ((e.g. ^master~10 ) или неявно (e.g. master~10..master , —since=10.days.ago master ).

Все эти простые случаи в порядке (при условии, что у нас есть «мастер» и «следующий» 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

И вот эти (и такие же, но опущенные —stdin examples):

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

Имя ревизии или диапазон, правая часть которого не может быть преобразована в ссылку, не принимается:

$ 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

При создании пакетов можно создать автономный пакет, который можно разделить в репозитории без общей истории, а также предоставить отрицательные версии для исключения объектов, необходимых в более ранних частях истории.

При передаче ревизии, такой как new , в git bundle create будет создан пакетный файл, содержащий все объекты, доступные из ревизии new . Этот пакет можно разделить в любом репозитории, чтобы получить полную историю, ведущую к ревизии new :

$ git bundle create full.bundle new

Диапазон ревизий, такой как old..new , создаст пакетный файл, для которого потребуется, чтобы ревизия old (и любые доступные из нее объекты) существовала, чтобы пакет можно было «разделить»:

$ git bundle create full.bundle old..new

Самодостаточный бандл без всяких пререквизитов можно извлечь куда угодно, хоть в пустой репозиторий, или клонировать из (i.e., new , но не old..new ).

Можно ошибиться из соображений предосторожности, в результате чего файл пакета будет содержать объекты, уже находящиеся в месте назначения, поскольку они игнорируются при распаковке в месте назначения.

Если вы хотите сопоставить git clone —mirror , который будет включать ваши ссылки, такие как refs/remotes/* , используйте —all . Если вы хотите предоставить тот же набор ссылок, который получил бы клон непосредственно из исходного репозитория, используйте —branches —tags для .

Команду git bundle verify можно использовать, чтобы проверить, есть ли в вашем репозитории получателя необходимые предварительные фиксации для пакета.

Examples

Предположим, вы хотите перенести историю из репозитория R1 на машине A в другой репозиторий R2 на машине B. По какой-то причине прямое соединение между A и B не разрешено, но мы можем перемещать данные из A в B с помощью какого-либо механизма. Электронная почта (CD,, etc.)..

Чтобы запустить процесс, вы можете сначала создать пакет, который не имеет никаких предварительных условий. Вы можете использовать тег, чтобы запомнить, до какой фиксации вы обрабатывали в последний раз, чтобы упростить позднее обновление другого репозитория с помощью добавочного пакета:

machineA$ cd R1 machineA$ git bundle create file.bundle master machineA$ git tag -f lastR2bundle master

Затем вы переносите file.bundle на целевую машину B. Поскольку этот пакет не требует извлечения какого-либо существующего объекта, вы можете создать новый репозиторий на машине B, клонировав ее:

machineB$ git clone -b master /home/me/tmp/file.bundle R2

Это определит удаленный объект под названием «источник» в результирующем репозитории, который позволит вам извлекать и извлекать из пакета. Файл $GIT_DIR/config в R2 будет иметь такую запись:

[remote "origin"] url = /home/me/tmp/file.bundle fetch = refs/heads/*:refs/remotes/origin/*

Чтобы обновить результирующий репозиторий mine.git, вы можете извлечь или извлечь после замены пакета, хранящегося в /home/me/tmp/file.bundle, добавочными обновлениями.

Поработав еще немного в исходном репозитории, вы можете создать инкрементный пакет для обновления другого репозитория:

machineA$ cd R1 machineA$ git bundle create file.bundle lastR2bundle..master machineA$ git tag -f lastR2bundle master

Затем вы переносите пакет на другой компьютер, чтобы заменить /home/me/tmp/file.bundle,, и извлекаете из него.

machineB$ cd R2 machineB$ git pull

Если вы знаете, до какой фиксации предполагаемый репозиторий-получатель должен иметь необходимые объекты, вы можете использовать эти знания, чтобы указать предварительные условия, задав точку отсечения для ограничения ревизий и объектов, которые go в результирующем пакете. В предыдущем примере для этой цели использовался тег lastR2bundle, но вы можете использовать любые другие параметры, которые вы указали бы для команды git-log[1] . Вот еще примеры:

Вы можете использовать тег, который присутствует в обоих:

$ git bundle create mybundle v1.0.0..master

Вы можете использовать предварительное условие в зависимости от времени:

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

Вы можете использовать количество коммитов:

$ git bundle create mybundle -10 master

Вы можете запустить git-bundle verify , чтобы узнать, можете ли вы извлечь из пакета, созданного с предварительным условием:

$ git bundle verify mybundle

В нем будут перечислены коммиты, которые вы должны иметь для извлечения из пакета, и будет ошибка, если у вас их нет.

Пакет с точки зрения репозитория-получателя ничем не отличается от обычного репозитория, из которого он извлекается или извлекается. Вы можете, например, отображать ссылки при выборке:

$ git fetch mybundle master:localRef

Вы также можете увидеть, какие ссылки он предлагает:

$ git ls-remote mybundle