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

Question

У меня есть местный филиал для повседневной работы разработчиков в git. Мой рабочий процесс:

1. Делать вещи на local_branch, фиксировать
2. Получение происхождения / мастер
3. Перебазировать local_branch, чтобы догнать новые вещи из origin / master

Все это прекрасно работает, однако большинство рекомендаций, с которыми я столкнулся, говорят о том, что не следует «выдвигать» частные ветки, для которых регулярно выполняется ребазинг.

Проблема здесь заключается в том, что в этом случае локальная ветвь не резервируется на сервере, и единственный способ сохранить работу - это объединить ее с «pushable» ветвью (т.е. origin / master)

Каковы были бы ваши рекомендации относительно рабочего процесса в этом случае?

Спасибо!

ОБНОВЛЕНИЕ : я понял, что одно из моих первоначальных требований (исключая использование внешних утилит) - ненужное ограничение.

Мое текущее решение - хранить все мои репозитории в папке с синхронизацией в облаке - таким образом, я получаю резервное копирование бесплатно.

Answer 1

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

Добавить в качестве удаленного:

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

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

git push --mirror bak

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

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

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

Answer 2

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

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

Answer 3

Еще один вариант - отправить local_branch в репо «origin», но в свою собственную ветку в этом репо (не «master»), т. Е .:

git push origin local_branch:local_backup

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

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

git push origin local_branch:local_backup

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

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

Answer 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»).

Answer 5

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

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

Answer 6

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

Answer 7

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