close
Image
українська мова ▾ Topics ▾ Latest version ▾ git-bundle last updated in 2.48.0

НАЗВА

git-bundle — Переміщення об’єктів та посилань шляхом архівування

СИНОПСИС

git bundle create [-q | --quiet | --progress]
		    [--version=<version>] <file> <git-rev-list-args>
git bundle verify [-q | --quiet] <file>
git bundle list-heads <file> [<refname>…​]
git bundle unbundle [--progress] <file> [<refname>…​]

ОПИС

Створення, розпакування та обробка файлів «bundle». Файли «bundle» використовуються для «офлайн»-передачі об’єктів Git без активного «сервера» на іншому кінці мережевого з’єднання.

Їх можна використовувати для створення як інкрементальних, так і повних резервних копій репозиторію (див. приклад «повної резервної копії» в розділі «ПРИКЛАДИ»), а також для передачі стану посилань з одного репозиторію до іншого (див. другий приклад).

Команди Git, які завантажують або іншим чином «зчитують» дані через протоколи, такі як ssh:// та https://, також можуть працювати з файлами набору (bundle). Можна створити нове сховище з набору за допомогою git-clone[1], завантажити дані з нього за допомогою git-fetch[1] та вивести список посилань, що містяться в ньому, за допомогою git-ls-remote[1]. Відповідної підтримки «запису» немає, тобто команда git push у пакунок не підтримується.

ФОРМАТ НАБОРУ

Набори (bundles) — це файли .pack (див. git-pack-objects[1]) із заголовком, що вказує на те, які посилання містяться в ньому.

Так само, як і сам формат стисненого архіву, набори можуть бути або самостійними, або створюватися з використанням виключень. Див. розділ «ВИМОГИ ДО ОБ’ЄКТІВ» нижче.

Набори, створені за допомогою виключень ревізій, є "тонкими пакунками", створеними за допомогою опції --thin для git-pack-objects[1], та розпакованими за допомогою опції --fix-thin для git-index-pack[1].

Немає опції створення «товстого пакунка» під час використання виключень редакцій, і користувачам не варто турбуватися про цю різницю. Завдяки використанню «тонких пакунків» набори, створені за допомогою виключень, мають менший розмір. Те, що вони «тонкі» під капотом, зазначається тут лише як додаткові відомості та як посилання на іншу документацію.

Див. gitformat-bundle[5] для отримання додаткової інформації та обговорення "тонкого пакунку" у gitformat-pack[5] для отримання додаткової інформації.

ОПЦІЇ

create [параметри] <file> <git-rev-list-args>

Використовується для створення пакунка з назвою file. Для цього потрібні аргументи <git-rev-list-args> для визначення вмісту пакета. Параметри містять опції, специфічні для субкоманди git bundle create. Якщо file має значення -, пакунок виводиться в stdout.

verify <file>

Використовується для перевірки того, чи файл набору є дійсним і чи можна його без проблем застосувати до поточного репозиторію. Це включає перевірку самого формату набору, а також перевірку наявності необхідних комітів та їх повного зв’язування в поточному репозиторії. Потім команда git bundle виводить список відсутніх комітів, якщо такі є. Нарешті, виводиться інформація про додаткові можливості, такі як «фільтр обʼєктів». Дивіться «Можливості» у gitformat-bundle[5] для отримання додаткової інформації. Код завершення дорівнює нулю у разі успіху, але буде відмінним від нуля, якщо файл набору є недійсним. Якщо file дорівнює -, набір читається зі стандартного вводу.

list-heads <file>

Виводить перелік посилань, визначених в наборі. Якщо після нього наведено список посилань, виводяться лише посилання, що відповідають заданим. Якщо file має значення -, набір зчитується зі stdin.

unbundle <file>

Передає об’єкти з набору до git index-pack для збереження у репозиторії, а потім виводить імена всіх визначених посилань. Якщо вказано список посилань, виводяться лише ті посилання, що відповідають зазначеним у списку. Ця команда є суто технічною і призначена для виклику виключно командою git fetch. Якщо аргумент file має значення -, набір зчитується з stdin.

<git-rev-list-args>

Список аргументів, що приймаються командами “git rev-parse” та “git rev-list” (і містить вказане посилання, див. розділ ВИЗНАЧЕННЯ ПОСИЛАНЬ нижче), який визначає конкретні об’єкти та посилання, що підлягають передачі. Наприклад, master~10..master призводить до того, що поточне посилання master буде упаковано разом з усіма об’єктами, доданими починаючи з його 10-го попереднього коміту. Явного обмеження на кількість посилань та обʼєктів, які можуть бути упаковані, немає.

[<refname>…​]

Список посилань, що використовується для обмеження посилань, що повідомляються як доступні. Це головним чином корисно для git fetch, який очікує отримати лише ті посилання, що запитуються, а не обовʼязково все з набору (у цьому випадку git bundle діє як git fetch-pack).

--progress

Якщо не вказано параметр -q, інформація про хід виконання типово виводиться у стандартний потік помилок, коли програма підключена до терміналу. Цей параметр примусово виводить інформацію про хід виконання, навіть якщо стандартний потік помилок не спрямований до терміналу.

--version=<version>

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

-q
--quiet

Цей прапорець змушує команду не виводити інформацію про хід виконання у стандартний потік помилок.

ВИЗНАЧЕННЯ ПОСИЛАНЬ

До ревізій необхідно додати імена посилань, які потрібно включити до набору. Крім того, для включення всіх посилань можна використати опцію --all.

Можна упакувати більше одного посилання та вказати більше одного набору обʼєктів, що є попередніми умовами. Упаковуються ті обʼєкти, які не входять до об’єднання передумов.

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

Усі ці прості випадки прийнятні (якщо припустити, що у нас є гілки "master" та "next"):

$ 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):

$ 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)
фатальний результат: Відмова у створенні порожнього набору.
$ git bundle create master-yesterday.bundle master~10..master~5
фатальний результат: Відмова у створенні порожнього набору.

ВИМОГИ ДО ОБ’ЄКТІВ

Під час створення наборів можна створити автономний набір, який можна розпакувати в репозиторії без спільної історії, а також надати негативні ревізії, щоб виключити обʼєкти, необхідні в попередніх частинах історії.

Передавання ревізії, такої як new, до git bundle create створить файл набору, який містить усі обʼєкти, доступні з ревізії new. Цей набір можна розпакувати в будь-якому репозиторії, щоб отримати повну історію, яка веде до ревізії new:

$ git bundle create full.bundle new

Діапазон ревізій, такий як old..new, створить файл набору, який вимагатиме існування ревізії old (та будь-яких обʼєктів, доступних з неї), щоб набір можна було "розпакувати":

$ git bundle create full.bundle old..new

Автономний набір без будь-яких передумов можна розпакувати будь-куди, навіть у порожній репозиторій, або клонувати з нього (тобто new, але не old..new).

Немає нічого страшного в тому, щоб перестрахуватися і включити до файлу набору об’єкти, які вже знаходяться у місці призначення, оскільки під час розпакування у місці призначення вони ігноруються.

Якщо ви хочете надати той самий набір посилань, який отримав би клон безпосередньо з вихідного репозиторію, використовуйте --branches --tags для <git-rev-list-args>.

Команду git bundle verify можна використовувати для перевірки того, чи має ваш репозиторій-одержувач необхідні коміти для набору.

ПРИКЛАДИ

Ми розглянемо два випадки:

  1. Створення повної резервної копії репозиторію

  2. Перенесення історії репозиторію на іншу машину, коли дві машини не мають прямого зʼєднання

Спочатку розглянемо повну резервну копію репозиторію. Наступна команда створить повну резервну копію репозиторію, тобто всі посилання будуть включені до набору:

$ git bundle create backup.bundle --all

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

Ви можете пізніше відновити цей репозиторій, використовуючи, наприклад, git-clone[1]:

$ git clone backup.bundle <new directory>

Для наступного прикладу припустимо, що ви хочете перенести історію з репозиторію R1 на машині A до іншого репозиторію R2 на машині B. З якоїсь причини пряме зʼєднання між A та B заборонено, але ми можемо перемістити дані з A до B за допомогою певного механізму (компакт-диск, електронна пошта тощо). Ми хочемо оновити R2, враховуючи розробку, виконану в головній гілці в R1.

Щоб запустити процес, спочатку можна створити набір без жодних попередніх вимог. Ви можете використовувати тег, щоб запамʼятати, який коміт ви обробили востаннє, щоб пізніше було легше оновити інший репозиторій за допомогою інкрементального набору:

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

Це визначить віддалений екземпляр з назвою "origin" в отриманому репозиторії, який дозволить вам отримувати дані з набору. Файл $GIT_DIR/config у R2 матиме запис:

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

Щоб оновити отриманий репозиторій mine.git, ви можете скористатися fetch або pull після заміни набору, що зберігається в /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

Якщо ви знаєте, до якого коміту цільовий репозиторій-отримувач повинен містити необхідні обʼєкти, ви можете використати ці знання для визначення попередніх вимог, встановивши граничну точку для обмеження ревізій та обʼєктів, що потрапляють до фінального набору. У попередньому прикладі для цієї мети використовувався тег 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

ОБГОВОРЕННЯ

Найпростіший спосіб створити повну резервну копію репозиторію — це скористатися командою на кшталт cp -r <repo> <destination>. Однак це не рекомендується, оскільки під час копіювання в репозиторій можуть надходити нові дані. Своєю чергою, це може призвести до пошкодження деяких файлів у теці <destination>.

Ось чому рекомендується використовувати інструменти Git для створення резервних копій репозиторіїв, або за допомогою цієї команди, або, наприклад, git-clone[1]. Але майте на увазі, що ці інструменти не допоможуть вам створити резервну копію стану, окрім посилань та комітів. Іншими словами, вони не допоможуть вам створити резервну копію вмісту індексу, робочого дерева, сховища, конфігурації для кожного репозиторію, гачків тощо.

Див. також gitfaq[7], розділ «ПЕРЕДАЧІ» для висвітлення проблем, повʼязаних із синхронізацією файлів між системами.

ФОРМАТ ФАЙЛУ

Див. gitformat-bundle[5].

GIT

Частина набору git[1]