частная ветка mercurial / git для бэкапа?

Question

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

Answer 1

По умолчанию git clone и git fetch/merge загружают только ссылки в refs /heads / *. Поэтому все, что вы нажимаете в другом месте, не будет загружаться другими (если они явно не просят их или не делают что-то вроде git clone --mirror). Так, например, вы можете сделать:

git push origin HEAD:refs/koen/my_work

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

git pull origin refs/koen/my_work

Чтобы автоматизировать нажатие на ГОЛОВУ, вы можете сделать что-то вроде

[remote "origin"]
    url = git@github.com:pieter/gitx.git
    push = :
        push = refs/heads/*:refs/koen/*

, который подтолкнет все ваши ветви к пульту, не мешая никому. Это также сохранит стандартное поведение push, к которому вы привыкли. Если вы этого не хотите, удалите строку push = :.

Answer 2

Git позволяет очень легко отражать ваш репозиторий;

Допустим, у вас есть удаленное хранилище с именем 'backup', например,

git remote add --mirror backup server.com:/home/koen/backup_repo.git

Тогда резервное копирование так же просто, как

git push backup

Несколько заметок:

• если вы не использовали --mirror при добавлении удаленного репо, тогда используйте --mirror в вашей команде push
• удаленный репозиторий должен быть «голым» репозиторием (так как вы продвигаетесь в него)
• Оформить справку git push и git remote относительно --mirror

Answer 3

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

• Создайте свой собственный второй репозиторий в отдельном месте и отправляйте туда свою ветку разработки в конце каждого дня. Вы бы не поставили свою ветку разработки на стабильную, которую все остальные используют.

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

Answer 4

Это можно сделать, если у вас есть два удаленных клона хранилища:

stable
unstable

Нажмите нестабильно (ваша резервная копия), пока вы не закончили функцию. Как только функция будет завершена, переместите ветку в стабильное состояние. Вспенить, промыть, повторить.

Answer 5

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

In ~ / .gitconfig

[alias]
  backup = !git push -v origin +refs/heads/*:refs/wip/`git config --get user.email`/*

Таким образом, вы можете в любое время запустить локальное репо:

git backup

Все ваши локальные ветки (в любом случае под refs /heads) будут помещены в репо "origin" в пространстве имен refs / wip / your_email /, безусловно (так же, как push -f).

Как только вы будете готовы перейти к исходному / главному устройству, если вы использовали это для резервного копирования текущей работы, push будет действительно быстрым, поскольку большинство (все) объектов SHA1 уже находятся на исходный сервер.

Обратите внимание, что время от времени вы захотите очистить резервные копии, чтобы исходное хранилище могло собирать мусор. См:

git ls-remote origin refs/wip/`git config --get user.email`/*

Это даст вам список веток, которые вы выдвинули в резервные копии, чтобы вы могли знать / автоматизировать, что нужно чистить.

Answer 6

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

Тогда у вас есть открытый репозиторий , что означает, что у него нет рабочего репозитория. Вы переходите в этот общедоступный репозиторий (который может быть, например, размещен на одном из сайтов git-хостинга, таких как repo.or.cz , GitHub или Gitorious ) с вашего частный репозиторий, когда ваши работы стабилизируются. Вы можете отправить только подмножество веток из своего частного репозитория разработки в этот публичный публикационный репозиторий (например, сопровождающий Git, Junio ​​C Hamano, не продвигает функциональные ветви в публичном git.git хранилище). Это общедоступное хранилище, откуда другие люди берутся.

Это разделение имеет то преимущество, что вы можете исправлять коммиты (например, используя "git commit --amend"), которые не помещаются в общедоступный репозиторий, и в противном случае переписывать части истории, которые присутствуют только в частном репозитории разработки.

Answer 7

Я думаю, что это зависит больше от того, как ваш репозиторий сделан видимым и какие у вас есть разрешения. В принципе, вам просто нужна временная ветка для использования в качестве «области сохранения», которую вы отправляете в репозиторий-концентратор - я думаю, вы уже это знаете. Есть ли общий способ пометить ветку как "невидимую"? Я не верю в это, хотя вы могли бы поэкспериментировать с переводом вашей локальной ссылки на ссылки со странным именем на другом конце, например ::

git push central refs/heads/master:refs/remotes/tmp/master

Это попыталось бы создать "refs / remotes / tmp / master", которое является действительным именем refN, но не тем, которое обычно считается ветвью. Например, gitweb покажет такую ​​ссылку, если она появится в истории одной из веток под ссылками / заголовки /, но не покажет список всех удаленных ссылок.

В качестве альтернативы, просто прикусите пулю и протолкните в видимую ветвь, называемую «вероятно, сломан, используйте по вашему усмотрению»;)

Answer 8

Последняя версия TortoiseHg позволяет вам отложить ваши изменения .

В двух словах:

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

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

Answer 9

С Mercurial, когда вы объединяете, вы объединяете все ваши наборы изменений , включая эти коммиты "только для сохранения незаконченной работы" Если вы не хотите, чтобы они заканчивались на дереве, не передавайте их.

Насколько я знаю, для git поведение по умолчанию такое же, и редактирование истории коммитов для их удаления также раздражает.

Итак, как и предполагалось, rsync выглядит как лучший вариант.

Answer 10

В нашем ртутном проекте мы используем несколько веток. Ветвь по умолчанию похожа на «ствол». Каждый раз, когда я запускаю функцию, я разветвляюсь и развиваюсь там. Я фиксирую, толкаю, иду в другое место, дергаю, фиксирую, толкаю. Ветвь по умолчанию остается нетронутой, а все остальные не щадят мою ветку. Когда я закончу, я объединяю ветку с настройками по умолчанию.