Вести точную глубокую копию удаленного хранилища

Question

Я пытаюсь сохранить точную копию (резервную копию) моего удаленного хранилища. Я запускаю задание cron каждый день, пытаясь обновиться с пульта. Я хотел бы обновить хранилище, включая все ветви, теги и т. Д. c. Я читал об использовании опции --mirror в git, но исходный код не загружается. Кроме того, мне также необходимо добавить или удалить все ветви или теги, которые были добавлены на удаленный компьютер.

Учитывая, что мой пульт имеет имя origin, в настоящее время я выполняю следующие действия:

// clone
git clone --mirror https://my_site.com/path/to/repo.git repo/.git
// track all remotes
for remote in `git branch -r | grep -v /HEAD`; do git checkout --track $remote ; done
git fetch --all
git pull --all

This Метод работает нормально, но он пытается извлекать удаленный при каждом запуске, а не при обнаружении новой удаленной ветви. Кроме того, он не удаляет локальную ветвь, если она была удалена с удаленного. То же самое для тегов, я думаю.

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

Answer 1

Зеркальный клон - это пустой клон, в который все имена ссылок копируются на каждый git fetch. Следовательно, чтобы обновить зеркальный клон, вам нужно только запустить git fetch на пульте дистанционного управления, который зеркалируется (обычно это источник): git fetch origin или просто git fetch, и когда это будет сделано, ваше зеркало обновится.

Я читал об использовании параметра --mirror в git, но он не загружает исходный код.

Это утверждение не имеет смысла для меня. Git не имеет "источника": Git имеет коммитов . Каждый коммит имеет полный и полный снимок каждого файла. Если у вас есть коммиты, у вас есть файлы: не исходный , а каждый файл (в каждом коммите).

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

до использование зеркального клона, Например, чтобы построить что-то, вы должны клонировать его в обычный (не зеркальный, не голый) клон. Затем вы можете добавить дополнительный пульт к этому обычному клону. Если вы хотите сделать новые коммиты в этом обычном клоне, а затем отправить эти новые коммиты в репозиторий, из которого вы создали зеркальный клон, вам понадобится этот дополнительный пульт, чтобы назвать URL, на котором находится этот другой репозиторий.

Следовательно, достаточно полным примером может быть:

cd place-where-mirrors-live
git clone --mirror $URL mirror.git

, за которым следует:

cd place-to-work
git clone /path/to/place-where-mirrors-live/mirror.git working
cd working
git remote add upstream $URL
git checkout -b some-new-branch
... do work ...
git commit
git push upstream -u HEAD

, за которым следует:

(cd /path/to/where-mirrors-live/mirror.git && git fetch --prune)

для обновления зеркала в mirror.git на основе обновления, которое вы сделали в working и затем отправили в репозиторий Git на $URL с вашим git push.

Если вы удалили ветку в Git на $URL с использованием:

git push upstream --delete some-branch

шаг git fetch --prune удалит ветку в зеркале. Вы можете sh настроить fetch.prune на true в зеркале или в вашей (--global) Git конфигурации, чтобы каждые git fetch были git fetch --prune .

Вы можете, если вы действительно старую школу по этому поводу, захотеть использовать git remote update --prune для обновления своего зеркала, но это не должно делать ничего такого, чего git fetch --prune не делал бы. (В далеком прошлом было несколько Git ошибок в этой общей области: не все черносливы работали для всех случаев.)