В чем разница между объединением и архивированием репозитория git?

#git

#git

Вопрос:

Когда я выполняю

 git bundle create ../`basename $PWD`.all.gitbundle --all
  

в репозитории git созданный файл пакета имеет размер около 4,8 МБ. Когда я архивирую всю папку репозитория, результирующий файл имеет 26,2 МБ.

В основном я ищу способ резервного копирования всего репозитория без потери какой-либо информации. Но, учитывая различия в размерах архивированных файлов, я предполагаю git bundle , что резервное копирование не всего или более эффективно, чем простой zip.

Не мог бы кто-нибудь, пожалуйста, пролить свет на это?

Комментарии:

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

2. @KingCrunch: строго говоря, клон не является «копией», поскольку структура ветвей отличается. Если вам нужна настоящая копия, вы хотите добавить флаг —mirror к своему клону. Это сделает структуру ветвей клона точно такой же, как у оригинала.

3. Даже зеркало не является точной копией каталога вашего репозитория. Вы по-прежнему будете пропускать любые пользовательские настройки, которые могут быть у вас в вашем файле .git / config, вы по-прежнему будете пропускать свой тайник, любую работу, которую вы, возможно, выполняете, свою рабочую область — практически все, что не записано в репозитории.

Ответ №1:

Команда bundle упакует все, что обычно передается по проводам с помощью git push

http://progit.org/2010/03/10/bundles.html

Это означает, что в пакете не будет устаревших объектов и т. Д., Которые Будут частью вашего репозитория. Кроме того, вы не должны считать фактические файлы в рабочем каталоге вашего репозитория, а только объекты .git with и другие метаданные, поскольку именно они будут содержать пакет, а не файлы в их первоначальном виде.

Для резервного копирования вы можете использовать git clone --mirror опцию using или просто архивировать репозиторий, как вы это сделали. Пакет не является жизнеспособным вариантом резервного копирования для репозитория, так как вы потеряете конфигурацию, рефлог, устаревшие объекты и т. Д.

Ответ №2:

Я думаю, что git использует zlib для сжатия.

zip тем не менее, это не лучший формат архивирования, когда дело доходит до размера. zlib использует дельта-сжатие для дальнейшего уменьшения размера, что и есть (спасибо Википедии):

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

Это может объяснить ваш крошечный размер файла. Я попробовал a file в выделенном пакете git, и он сказал, что пакет — это просто необработанные данные.

Комментарии:

1. Я думаю, вы немного дезинформированы. сжатие zlib использует дельта-кодирование как часть того, как оно работает (это в основном то, как работает все сжатие). Сам Git сохраняет полные файлы без дельта-файлов в виде объектов в своем репозитории, а затем использует zlib для выполнения дельта-сжатия (git также достаточно умен, чтобы повторно использовать дельты при выполнении инкрементной упаковки для ускорения операций).

2. Упс. Тогда, я думаю, он просто использует zlib .

Ответ №3:

Я не нахожу git-bundle хорошей идеи для сохранения резервной копии вашего репозитория. Либо создайте пустой репозиторий и поместите в него ссылки, которые вы хотите отслеживать в своей резервной копии, либо используйте старые добрые архивы. Разница между ними заключается в том, что нажатие позволяет создавать резервные копии только выборочных ветвей. Например, вы можете игнорировать ветки scratch в своих резервных копиях. Архивирование вашего репозитория приведет к созданию резервных копий абсолютно всего, включая ваш тайник, неотслеживаемые файлы, объектные файлы и любые временные файлы редактора.

Обычно я просто архивирую все это. Вы можете запустить git-clean -fdxn , а затем git-clean -fdx тщательно удалить все, что не хранится в вашем репозитории. Если вы действительно настаиваете на эффективности размера при выполнении резервного копирования (а вы не должны; просто позвольте Git беспокоиться об этом), тогда вы можете собирать мусор перед резервным копированием и, возможно, даже обрезать свой рефлог. Но вы знаете, я бы не стал. В наши дни хранилище дешево, и, поступая так, вы просто теряете ценность резервной копии.