Есть ли простой способ сделать резервную копию всего репозитория git, включая все ветви и теги?

Как насчет просто сделать его клоном?

git clone --mirror other/repo.git

Каждый репозиторий является резервной копией своего удаленного.

git bundle

Мне нравится этот метод, так как в результате получается всего один файл, который легче копировать.
Смотрите ProGit: маленький пучок радости .
Смотрите также « Как я могу послать кому-нибудь письмо с git-репозиторием? », Где команда

git bundle create /tmp/foo-all --all

подробно:

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

Для использования этого пакета вы можете клонировать его, указав несуществующую папку (вне любого git-репо):

git clone /tmp/foo-all newFolder

Развивая некоторые другие ответы, это то, что я делаю:

Настройте репо: git clone --mirror user@server:/url-to-repo.git

Затем, когда вы хотите обновить резервную копию: git remote updateиз местоположения клона.

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

Это атомарно, поэтому не имеет проблем, которые могут возникнуть у простой копии.

См. Http://www.garron.me/en/bits/backup-git-bare-repo.html.

Расширяя великолепные ответы KingCrunch и VonC

Я объединил их обоих:

git clone --mirror git@some.origin/reponame reponame.git
cd reponame.git
git bundle create reponame.bundle --all

После этого у вас есть файл, reponame.bundleкоторый можно легко скопировать. Затем вы можете создать новый нормальный git-репозиторий, используя это git clone reponame.bundle reponame.

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

Все содержится в .gitкаталоге. Просто сохраните это вместе с вашим проектом, как любой файл.

использовать git bundle или клонировать

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

Вы можете сделать резервную копию git-репозитория с помощью git-copy с минимальным объемом хранилища.

git copy /path/to/project /backup/project.repo.backup

Затем вы можете восстановить свой проект с git clone

git clone /backup/project.repo.backup project

Правильный ответ IMO - git clone --mirror . Это полностью сделает резервную копию вашего репо.

Git clone mirror клонирует весь репозиторий, заметки, заголовки, ссылки и т. Д. И обычно используется для копирования всего репозитория на новый git-сервер. Это уничтожит все ветки и все, весь репозиторий.

git clone --mirror git@example.com/your-repo.git

• Обычно клонирование репо не включает все ветви, только Мастер.

• Копирование папки репо будет «копировать» только те ветки, которые были извлечены ... поэтому по умолчанию это только основная ветка или другие ветви, которые вы извлекли ранее.

• Команда Git bundle также не то, что вам нужно: «Команда bundle упакует все, что обычно передается по проводам, с помощью команды git push в двоичный файл, который вы можете отправить кому-либо по электронной почте или поместить на флэш-диск, а затем распутать в другое хранилище. " (В чем разница между git clone --mirror и git clone --bare )

Этот поток был очень полезен, чтобы получить некоторое представление о том, как можно создавать резервные копии git-репозиториев. Я думаю, что все еще не хватает некоторых подсказок, информации или заключения, чтобы найти «правильный путь» (тм) для себя. Поэтому делюсь своими мыслями здесь, чтобы помочь другим, и выставлять их на обсуждение, чтобы улучшить их. Спасибо.

Итак, начнем с подбора исходного вопроса:

• Цель состоит в том, чтобы максимально приблизиться к «полной» резервной копии репозитория git.

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

• Резервное копирование через «горячее копирование» является предпочтительным, чтобы избежать простоев службы.
• Недостатки git будут обходиться дополнительными командами.
• Сценарий должен выполнять резервное копирование, чтобы объединить несколько шагов в одну резервную копию и избежать ошибок человека (опечаток и т. Д.).
• Кроме того, сценарий должен выполнить восстановление, чтобы адаптировать дамп к целевому компьютеру, например, даже конфигурация исходного компьютера могла измениться после резервного копирования.
• Среда - это git-сервер на компьютере с Linux, файловая система которого поддерживает жесткие ссылки.

1. Что такое «полная» резервная копия git-репо?

Точка зрения отличается от того, что такое «100%» резервное копирование. Вот два типичных.

# 1 Точка зрения разработчика

• содержание
• Ссылки

git - инструмент для разработчиков и поддерживает эту точку зрения через git clone --mirrorи git bundle --all.

# 2 Точка зрения администратора

• Файлы содержимого
  • Особый случай "packfile": git объединяет и уплотняет объекты в packfiles во время сборки мусора (см. git gc)
• Конфигурация мерзавца
  • см. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
  • документы: man git-config, man gitignore
  • .git / конфигурации
  • .git / description (для хуков и инструментов, например хук после получения электронной почты, gitolite, GitWeb и т. д.)
  • .git / Крючки /
  • .git / info / (исключить репозиторий и т. д.)
• Дополнительно: конфигурация ОС (разрешения файловой системы и т. Д.)

git - инструмент для разработчиков, и оставляет это администратору. Резервное копирование конфигурации git и конфигурации ОС следует рассматривать как отдельное от резервного копирования содержимого.

2. Техника

• "Cold-Copy"
  • Остановите службу, чтобы иметь эксклюзивный доступ к ее файлам. Простои!
• "Hot-Copy"
  • Сервис предоставляет фиксированное состояние для целей резервного копирования. Текущие изменения не влияют на это состояние.

3. Другие темы для размышления

Большинство из них являются общими для резервных копий.

• Достаточно ли места для хранения полных резервных копий? Сколько поколений будет храниться?
• Требуется ли поэтапный подход? Сколько поколений будет храниться и когда снова создавать полную резервную копию?
• Как проверить, что резервная копия не повреждена после создания или со временем?
• Поддерживает ли файловая система жесткие ссылки?
• Поместить резервную копию в один архивный файл или использовать структуру каталогов?

4. Что Git предоставляет для резервного копирования контента

• git gc --auto

  • документы: man git-gc
  • Очищает и сжимает репозиторий.

• git bundle --all

  • документы: man git-bundle, man git-rev-list
  • Atomic = "Hot-Copy"
  • Пакеты являются файлами дампа и могут использоваться напрямую с git (проверить, клонировать и т. Д.).
  • Поддерживает пошаговое извлечение.
  • Проверяется через git bundle verify.

• git clone --mirror

  • документы: man git-clone, man git-fsck, в чем разница между git clone --mirror и git clone --bare
  • Atomic = "Hot-Copy"
  • Зеркала - это настоящие git-репозитории.
  • Основное назначение этой команды - создать полное активное зеркало, которое периодически получает обновления из исходного хранилища.
  • Поддерживает жесткие ссылки для зеркал в той же файловой системе, чтобы избежать потери места.
  • Проверяется через git fsck.
  • Зеркала можно использовать как основу для полного резервного копирования файлов.

5. Холодная копия

Резервное копирование в режиме холодного копирования всегда может сделать полное резервное копирование файла: запретить все обращения к репозиториям git, сделать резервное копирование и разрешить доступ снова.

• Возможные проблемы
  • Может быть непросто - или даже невозможно - запретить любой доступ, например, общий доступ через файловую систему.
  • Даже если репозиторий находится на клиентском компьютере с одним пользователем, пользователь все равно может что-то зафиксировать во время автоматического резервного копирования :(
  • Время простоя может быть неприемлемым на сервере, а создание резервных копий нескольких крупных репозиториев может занять много времени.
• Идеи для смягчения:
  • Запретить прямой доступ к репо через файловую систему в целом, даже если клиенты находятся на одном компьютере.
  • Для доступа по SSH / HTTP используйте менеджеры авторизации git (например, gitolite) для динамического управления доступом или изменения файлов аутентификации в сценарии.
  • Резервное копирование репо, чтобы сократить время простоя для каждого репо. Запретите одно репо, сделайте резервную копию и снова разрешите доступ, затем продолжите со следующим репо.
  • Запланированный график обслуживания, чтобы избежать расстроенных разработчиков.
  • Только резервное копирование, когда хранилище изменилось. Может быть очень сложно реализовать, например, список объектов плюс наличие файлов пакетов, контрольные суммы конфигурации и хуков и т. Д.

6. Hot-Copy

Резервное копирование файлов не может быть выполнено с активными репозиториями из-за риска повреждения данных при текущих фиксациях. Оперативное копирование обеспечивает фиксированное состояние активного хранилища для целей резервного копирования. Текущие коммиты не влияют на эту копию. Как указано выше, git поддерживает функции клонирования и связки, но для резервного копирования «100% admin» необходимо выполнить несколько действий с помощью дополнительных команд.

Горячее копирование "100% admin"

• Вариант 1: используйте git bundle --allдля создания полных / инкрементных файлов дампа содержимого и копирования / резервного копирования файлов конфигурации отдельно.
• Вариант 2: использовать git clone --mirror, обрабатывать и копировать конфигурацию отдельно, затем выполнить полное резервное копирование файла зеркала.
  • Ноты:
  • Зеркало - это новый репозиторий, который заполняется текущим шаблоном git при создании.
  • Очистите файлы конфигурации и каталоги, затем скопируйте файлы конфигурации из исходного исходного хранилища.
  • Сценарий резервного копирования также может применять конфигурацию ОС, например, права доступа к файлам на зеркале.
  • Используйте файловую систему, которая поддерживает жесткие ссылки, и создайте зеркало в той же файловой системе, что и исходный репозиторий, чтобы повысить скорость и сократить использование пространства во время резервного копирования.

7. Восстановить

• Проверьте и примените конфигурацию git для целевой машины и новейшей философии «способа работы».
• Проверьте и адаптируйте конфигурацию ОС к целевой машине и последним принципам «способа работы».

cd /path/to/backupdir/
git clone /path/to/repo
cd /path/to/repo
git remote add backup /path/to/backupdir
git push --set-upstream backup master

это создает резервную копию и выполняет настройку, так что вы можете сделать git push, чтобы обновить резервную копию, что, вероятно, вы и хотите сделать. Просто убедитесь, что / path / to / backupdir и / path / to / repo - это как минимум разные жесткие диски, в противном случае это не имеет особого смысла.

Вот два варианта:

1. Вы можете напрямую взять tar из каталога git repo, поскольку он содержит все содержимое репо на сервере. Существует небольшая вероятность того, что кто-то может работать над репо во время резервного копирования.

2. Следующая команда даст вам чистый клон репо (точно так же, как он находится на сервере), затем вы можете взять tar из того места, где вы клонировали, без каких-либо проблем.

   git clone --bare {your backup local repo} {new location where you want to clone}
   

Если это на Github, перейдите к bitbucket и используйте метод "import repository", чтобы импортировать репозиторий github в качестве частного репо.

Если это в битбакете, сделайте наоборот.

Это полная резервная копия, но она остается в облаке, что является моим идеальным методом.

Насколько я знаю, вы можете просто сделать копию каталога, в котором находится ваш репо, и все!

cp -r project project-backup