Примечание. «Резервная» копия на том же компьютере не является большой частью резервной копии (особенно если она находится на том же диске).Чтобы быть надежным, вам действительно нужно скопировать свои данные на одну (или более!) Другую машину / носитель, предпочтительно в разные места.
Похоже, ваша «резервная копия» - это голое хранилище , но вы хотите, чтобы это был не пустой репозиторий (т. е. вы хотите, чтобы у него было проверено собственное рабочее дерево).
Проблема в том, что отправка в не пустой репозиторий обычно не является хорошей идеей.По сути, такие нажатия могут обновить ветку, на которую указывает HEAD, без обновления индекса или рабочего дерева.Это может привести к очень запутанным ситуациям в принимающем репозитории (например, добавленные файлы показаны с удаленным статусом и т. Д.).По этой причине в версиях Git 1.7.0 и более поздних по умолчанию отказываются принимать запросы в извлеченную в настоящее время ветвь ненастроенных репозиториев.
Примечание. При переносе в пустой репозиторий для целей резервного копирования всефайлы, содержащиеся в отправленных коммитах, есть, они просто не извлекаются (они сжимаются и хранятся в хранилище объектов Git как «свободные объекты» и «файлы пакета»).Выдвинутые данные представляют собой полную копию истории контента, который вы зафиксировали и отправили.Вы просто не можете получить доступ к контенту напрямую.Вместо этого вы должны клонировать его в репозиторий не-голого репозитория (и, таким образом, получить фиксацию) или использовать git archive для извлечения набора файлов без дополнительного репозитория или полной проверки.
Яне совсем уверен, что вам нужно что-то похожее на то, что вы описываете.
Если вам нужно изучить старый снимок вашего хранилища (и вам не хочется делать это в обычном рабочем хранилище), то вам просто нужно клонироватьвременная копия и проверка желаемого, старого коммита.Локальные клоны дешевы, так как они могут жестко связывать файлы хранилища объектов вместо их копирования.График исторической фиксации - это, как правило, все, что вам нужно, чтобы «вернуться в прошлое».Хотя Git позволит вам переписывать граф истории по своему усмотрению, вы не подвергаетесь большой опасности внесения невосстановимых изменений, поскольку обычно для этого требуются переключатели -f / --force и / или предусмотрены механизмы восстановления (reflogs, refs / original /, минимумвозрастные требования перед сбором объектов, на которые нет ссылок, и т. д.).
Это - это хорошая идея иметь другой репозиторий (особенно на другом компьютере в другом месте), куда вы можете отправлять свои коммиты в целях резервного копирования.(так что вы можете восстановить из (например) rm -rf working_repo), но чистого хранилища обычно вполне достаточно.Когда вам нужно восстановиться, вы просто делаете клон.Если вы хотите просмотреть какой-то старый снимок, не нарушая нормальное рабочее хранилище, вы делаете где-то временный клон.При надлежащей гигиене фиксации git diff, git log (особенно опции -p и -S) и git show могут часто предоставлять любую «археологическую» информацию, которая вам может потребоваться при старых фиксациях, без необходимости что-либо проверять.(они даже работают в голых репозиториях).
Однако, если вы готовы принять риск, вы можете делать именно то, что вы хотите.
Git, как и любой другой «острый»», Вы рискуете« выстрелить себе в ногу »(простите за смешанную метафору).
Создайте и настройте свой резервный репозиторий и добавьте его в качестве удаленного в рабочий репозиторий.
# paths to the repositories
WORKING=/path/to/working
BACKUP=/path/to/backup
# name for the backup repository in the working repository
REMOTE=backup
! test -d "$BACKUP" || (echo "error: $BACKUP already exists"; exit 1) &&
git clone --origin working "$WORKING" "$BACKUP" &&
( cd "$BACKUP" &&
git config receive.denyCurrentBranch false &&
git remote rm working
) &&
( cd "$WORKING" &&
git remote add "$REMOTE" "$BACKUP" &&
git config remote."$REMOTE".push 'refs/heads/*:refs/heads/*'
)
В хранилище резервных копий установите хук post-receive или post-update, который делает git reset --hard.Это будет поддерживать индекс и рабочее дерево в актуальном состоянии с текущей извлеченной веткой.
Git FAQ «Почему я не увижу изменения в удаленном репо после»git push "?" указывает на пример post-update script , который может сделать это относительно безопасно (он сохраняет тайник, если рабочее дерево или индекс грязные - это может привести к потере неотслеживаемых файлов, еслидобавляются только что добавленные файлы с теми же путями).
( H="$BACKUP"/.git/hooks/post-update &&
curl http://utsl.gen.nz/git/post-update >$H && chmod +x "$H" )
Нажмите для резервного копированияЕсли вы хотите обновить его.
(cd "$WORKING" && git push "$REMOTE")
Если вы используете такую настройку, вам следует полностью избегать работы в рабочем дереве резервного копирования. Любые коммиты, которые вы делаете там, любые поэтапные изменения, которые вы оставляете там, и любые неотслеживаемые файлы, которые вы оставляете там, могут быть потеряны.