Статьи

Git резервные копии, и нет, это не просто подталкивание

Git — это сама система резервного копирования: например, вы можете создавать версии ваших папок .txt, содержащих списки TODO. Поскольку Git версии ваших файлов так же, как это делается для кода, после случайного удаления или изменения он сможет вернуть вас.

Тем не менее, если вы не регулярно отправляете свои коммиты, проблема с диском, содержащим репозиторий, может привести к потере всей вашей работы . Вы можете поместить репозиторий в Dropbox или в похожий сервис, но я не верю в это. Dropbox синхронизирует файлы в .git независимо от остальных и друг от друга, и он может временно или бесполезно испортить хранилище. Кстати, я хочу снимать резервную копию только в определенные моменты времени, не всегда занимая мое соединение мгновенным зеркалированием.

Примечание перед началом: с двоичными данными Git не является опытным инструментом резервного копирования: текст работает намного лучше (это похоже на код). Эта статья посвящена резервному копированию кода и текстового содержимого.

Push не является резервной копией

Например, потому что может не хватать веток. Как правило, отправка в исходное состояние — это даже не вариант, поскольку вы, возможно, еще не хотите вносить изменения, но по-прежнему выполняете резервное копирование. Только в мире открытого исходного кода резервное копирование соответствует публикации в Интернете.

Однако благодаря децентрализации есть несколько простых решений, связанных с созданием репозитория, отличного от исходного:

git clone /path/to/working/copy #creates the backup
git pull #origin master of course, updates the backup
# you can specify better branches via the local configuration of the backup copy (git config)

Обратное решение, включающее вытягивание, также возможно:

git init . #in the folder of your backup, or you can use a remote repository
git remote add backup_repo /path/to/backup/repo #or a git:// repo
git push backup #master usually, but also multiple branches
git push --all backup #an alternative that pushes all branches

Все команды, а также те, которые будут следовать, являются просто командами bash: легко создать скрипт и автоматизировать его выполнение с помощью cron, anacron или чего угодно. Сила «del» Unix сильна в тебе.

Git Bundle

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

Для одной ветви это просто. Эта команда создаст файл myrepo.bundle.

git bundle create myrepo.bundle master

Для большего количества веток или тегов это все еще просто:

git bundle create myrepo.bundle master other_branch

Восстановление содержимого пакета является одним комментарием. Внутри пустого репо введите:

git bundle unbundle myrepo.bundle

Вместо этого, если у вас нет репо, и вы просто хотите восстановить старый:

git clone myrepo.bundle -b master myrepo_folder

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

Tar-

Альтернативой является просто архивирование репозитория в файле tar.gz или tar.bz.

tar -cf repository.tar repository/
gzip repository.tar # or bzip2 repository.tar

После этого вы можете использовать scp или даже rsync (но я не думаю, что это сильно ускорится), чтобы поместить repository.tar.gz на другой носитель.

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

Голые репозитории

Ты можешь использовать

git clone --bare repository/ backup_folder/

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

Этот метод может использоваться в сочетании с методом pull / push или tarball.

Для восстановления резервной копии:

git clone backup_folder/ new_repository/

воссоздаст исходную ситуацию в new_repository. В любом случае новые папки создаются автоматически. Я не советую просто копировать папку так часто, как в других файловых системах резервного копирования (например, vfat на USB-ключе), права, владелец и другие метаданные теряются.

Вывод

Итак, теперь у вас есть несколько альтернатив для резервного копирования ваших репозиториев или их транспортировки без настройки сервера, такого как Gitosis, или перехода с общедоступного Github. Фактически, я исследовал эту технику для переноса учебного кода на phpDay 2011 и голландскую PHP-конференцию, и они сработали довольно хорошо.