Как создать резервные копии частных веток в git

Ответ 1

Я использую параметр -mirror и нажимаю на личный резервный репозиторий:

Добавьте его как удаленный:

git remote add bak server:/path/to/backup/repo

Сделайте резервную копию:

git push --mirror bak

Это автоматически сделает ваш резервный репозиторий похожим на ваш активный. Если необходимо, будут созданы, удалены, обновлены (даже принудительно/не fastforwards) ветки. Вы также можете сделать псевдоним:

git config alias.bak "push --mirror bak"

Тогда это просто вопрос запуска "git bak", когда вы хотите сделать резервную копию. Вы также можете бросить это на работу cron.

Ответ 2

Другой вариант - нажать "local_branch" в репозиторий "origin", но на него есть собственная ветвь в этом репо (не "master" ), то есть:

git push origin local_branch:local_backup

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

git push origin :local_backup < === удаляет ветвь из источника

git push origin local_branch:local_backup

Таким образом, вы не столкнетесь с проблемами нажатия на "local_branch" после того, как он был переустановлен из "origin/master".

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

Ответ 3

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

Я использую префикс для обозначения "это моя ветка, используйте ее на свой страх и риск", например: fc-general-cleanup.

Ответ 4

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

Позволяет сказать, как выглядит граф фиксации после того, как вы разветкили local_branch и совершили пару попыток (C и D). Кто-то другой сделал одну фиксацию (E) в origin/master, так как вы разветвляли local_branch:

A -- B -- E  [origin/master]
      \
       \    
        \-- C -- D  [local_branch]

Затем после запуска "git rebase origin/master" граф фиксации будет выглядеть следующим образом. "origin/master" все тот же, но "local_branch" был переустановлен:

A -- B -- E  [origin/master]
           \
            \
             \-- C -- D  [local_branch]

На этом этапе, если вы выполните git push origin local_branch: master ", тогда это приведет к простой перемотке вперед. "origin/master" и "local_branch" будут идентичны:

A -- B -- E -- C -- D  [origin/master],[local_branch]

Теперь вы можете больше работать над "local_branch" . В конце концов вы можете получить что-то вроде этого:

A -- B -- E -- C -- D -- G -- I [origin/master]
                     \
                      \
                       \-- F -- H [local_branch]

Обратите внимание, что это очень похоже на начальный график. Вы можете продолжать повторять этот процесс снова и снова.

Вам следует избегать нажатия на другую ветку, из которой вы не переустанавливаете. Вот где вы столкнетесь с неприятностями (к другой ветке, это будет выглядеть так, как будто ваша история "local_branch" была внезапно переписана после того, как вы переустановили ее из "origin/master" ).

Ответ 5

Можете ли вы настроить другой удаленный репозиторий, на который вы нажимаете все ваши ветки? Другая вещь, которую стоит рассмотреть, - это просто создать резервную копию всего (важного) на вашей локальной машине, включая git repo.

Ответ 6

Вот что я делаю. Но - это не личное. Я делаю это так, чтобы я мог сотрудничать с собой (так сказать). Это позволяет мне работать в одной ветке на двух или более ящиках. если другие люди имели доступ к общему репо, они могли видеть работу, которую я делаю в филиале. Конечно, на моем домашнем репозитории никто не имеет доступа, поэтому он все еще частный. На github весь мир мог видеть мои вещи. Как будто они действительно заботятся.;)

Ответ 7

Вместо того, чтобы полагаться на Dropbox для синхронизации всех файлов репозитория git, я бы предпочел использовать git bundle, что производит только один файл (включая все ваши частные ветки) и синхронизирует этот файл с DropBox.
См. "Git с Dropbox"

В разделе Резервное копирование локального хранилища git, Ярс упоминается наличие ошибок синхронизации с Dropbox.