Возможно ли создать невидимую ветвь в git или mercurial, которую я могу использовать в качестве резервной копии? Например, в конце дня у меня есть незавершенная работа (может даже быть оставлена с синтаксическими ошибками), но я хочу, чтобы она была скопирована в репозиторий в Интернете, не раздражая других о том, что осталось.частная ртутная/git ветка для резервного копирования?
Это не цель SCM. Может быть, что-то вроде rsync, чтобы загрузить его на сервер, было бы лучшей идеей?
С mercurial, когда вы сливаетесь, вы объединяете все ваши изменения, включая те, которые совершают «только для сохранения незавершенной работы». Если вы не хотите, чтобы они заканчивались в дереве, не делайте их.
Для git, насколько мне известно, поведение по умолчанию одинаковое, и редактирование истории фиксации для их удаления также раздражает.
Итак, как было предложено, rsync выглядит как лучший вариант.
Вы могли бы сделать это, если у вас два удаленных клонов репозитория:
stable
unstable
Нажмите на нестабильный (резервного копирования) до тех пор, пока вы закончите функцию. Как только функция закончена, нажмите ветвь на стабильную. Намочите, промойте, повторите.
Последняя версия TortoiseHg позволяет вам shelve your changes.
В двух словах:
сукно изменения не физически удалены из рабочего каталога пока вы не unshelve них. Это означает, что вы можете создать проект и выполнить тесты на нем , в то время как отложенные изменения исчезли. Это безопаснее, чем выбрать изменения во время сборки, поскольку вы можете проверить , является ли сделанное изменение действительным.
Стеллаж изменения также полезно для удаления частично выполненной работы в убедиться, что он не мешает отладку других изменений вы решений.
Git позволяет вам легко зеркалировать репозиторий;
Предположим, у вас есть удаленное репо, называемое «резервным», например.,
git remote add --mirror backup server.com:/home/koen/backup_repo.git
Затем резервное копирование так же легко, как
git push backup
Несколько замечаний:
--mirror при добавлении удаленного репо, а затем использовать --mirror в вашем push commandgit push и git remote помощи в отношении --mirrorПо умолчанию git clone и git fetch/merge только скачать реф в работах/главах/*. Так что все, что вы нажимаете в другое место, не будет загружено другими (если они явно не просят их или не делают что-то вроде git clone --mirror). Так, например, вы можете:
git push origin HEAD:refs/koen/my_work
, чтобы нажать на текущую фиксацию. Используя этот полный refspec, вы можете вытащить его из другой проверки:
git pull origin refs/koen/my_work
Для автоматизации подталкивая ГОЛОВУ, вы могли бы сделать что-то вроде
[remote "origin"]
url = [email protected]:pieter/gitx.git
push = :
push = refs/heads/*:refs/koen/*
, что будет толкать все свои ветви на пульте дистанционного управления, не заботясь кто-нибудь еще. Он также будет поддерживать поведение push по умолчанию, к которому вы привыкли. Если вы этого не хотите, удалите строку push = :.
Я думаю, что это больше зависит от того, как ваш репозиторий становится видимым и какие разрешения у вас есть. В принципе, вам просто нужна ветвь temp для использования в качестве «области сохранения», которую вы нажимаете на репозиторий хаба. Я думаю, вы уже это знаете. Есть ли общий способ отметить ветку как «невидимую»? Я не верю, что это так, хотя вы можете экспериментировать с подталкивая местную голову исх к странному названию рефов на другом конце, например:
git push central refs/heads/master:refs/remotes/tmp/master
Это будет пытаться создать «ссылки/пульты Д/TMP/мастер» , который является действительным именем, но не тем, что обычно считается ветвью. Например, gitweb покажет такой ref, если он появится в истории одного из ветвей под refs/heads /, но не отобразит список всех удаленных ссылок.
В качестве альтернативы, просто стиснуть зубы и нажать на видимую ветвь под названием «вероятно, разбитая потребительный на Вашей опасности»;)
На нашем ртутный проекта мы используем несколько ветвей. Разделение по умолчанию похоже на «багажник». Каждый раз, когда я начинаю работу, я развожусь и развиваюсь там. Я совершаю, нажимаю, перехожу в другое место, тяну, совершаю, нажимаю. Филиал по умолчанию остается нецелевым, а все остальные не меняют ветку. Когда все будет готово, я объединю ветвь по умолчанию.
С Git, вы обычно частного хранилище, не голыми, что означает, что у него есть рабочий каталог. Вы создаете новые коммиты там, применяете патчи, вытягиваете/извлекаете из других репозиториев. Этот репозиторий размещается на вашей частной машине.
Тогда у вас есть общественного хранилища, голого, что означает, что он не имеет рабочий репозиторий. Вы нажимаете на этот публичный репозиторий (который может быть, например, размещен на одном из сайтов-сайтов git, таких как repo.or.cz, GitHub или Gitorious) из вашего частного хранилища, когда ваши работы стабилизируются. Вы можете нажать только подмножество ветвей из вашего частного хранилища развития для этого общественного издательского хранилища (например Git сопровождающему, Junio C Hamano, не нажмет художественных отделений в общественные git.git repositoris). Этот публичный репозиторий - это то место, откуда происходят другие люди.
Это преимущество имеет то преимущество, что вы можете исправить фиксации (например, используя «git commit -amend»), которые не попадают в общий репозиторий и в противном случае переписывают части истории, которые присутствуют только в частном репозитории развития.
Хотя это не является частным (кто-то в вашей компании может получить к ним, просто не по умолчанию, так что это не раздражает), это то, что я делаю:
В ~/.gitconfig
[alias]
backup = !git push -v origin +refs/heads/*:refs/wip/`git config --get user.email`/*
Итак, таким образом, вы можете в любое время на локальный счете репо:
git backup
Все ваших местных отделений (под ссылкой/руководители в любом случае) будут оттеснены к «происхождению» репо под рефами/wip/your_email/name пространство, безусловно (так же, как push -f).
Как только вы будете готовы нажать на источник/мастер, если вы использовали это для резервного копирования вашей работы, то нажатие будет очень быстрым, так как большинство (всех) объектов SHA1 будут уже на сервере происхождения.
Обратите внимание, что время от времени вы захотите очистить резервные копии, чтобы исходный репо мог мусор собирать вещи. См:
git ls-remote origin refs/wip/`git config --get user.email`/*
Это даст вам список филиалов вы подтолкнули к резервному копированию, так что вы можете знать/автоматизировать, что чистить.
Все, что вы нажимаете на общий репозиторий, будет повсеместно замечено/доступно. Ваши два простых варианта:
Создать свой второй репозиторий в отдельном месте и толкать развития отрасли, чтобы там в конце каждого дня. Вы бы не подталкивали свою ветвь развития к стабильной, которую все остальные используют.
Второй вариант, который не включает в себя наличие целого второго хранилища, но в конце дня займет больше работы с вашей стороны, это экспорт патчей для вашей работы. Стандартный метод исправления электронной почты git приведет к тому, что все ваши транзакции будут поддерживаться на случай, если вы захотите также создать резервную копию этого шаблона. Сжимайте патч и загружайте его где-нибудь.
Именно поэтому развитие в личной отрасли является общим/популярным, и это большая часть того, что делает распределенный VCS отличным. Перед фиксацией вы можете перейти на производственную ветвь, переустановить или объединить, как вы хотите, чтобы она была видна, а затем нажимать только те изменения, которые вы хотели.Rsync - плохой выбор для решения вопроса. –