частное подвижное ответвление / ответвление мерзавца для резервного копирования?

По умолчанию 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

Чтобы автоматизировать нажатие на вашу HEAD, вы можете сделать что-то вроде

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

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

Git позволяет очень легко зеркалировать хранилище;

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

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

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

git push backup

. Несколько замечаний:

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

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

stable
unstable

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

В mercurial, когда вы объединяете, вы объединяете все свои наборы изменений , включая те коммиты "только для сохранения незаконченной работы". Если вы не хотите, чтобы они заканчивались в дереве, не фиксируйте их.

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

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

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

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

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

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

I think this depends more on how your repository is made visible and what permissions you have. In principle, you just need a temp branch to use as a "save area" that you push to the hub repo--- I think you already know that. Is there a general way to flag a branch as "not visible"? I don't believe so, although you could experiment with pushing your local head ref to oddly-named refs on the other end, e.g.:

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

This would try to create "refs/remotes/tmp/master", which is a valid refname but not what is usually considered a branch. For instance, gitweb will show such a ref if it appears in the history of one of the branches under refs/heads/ but will not show a list of all the remote refs.

Alternatively, just bite the bullet and push to a visible branch called "probably-broken-use-at-your-peril" ;)

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

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

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

Это не совсем цель СКМ. Может быть, что-то вроде rsync для загрузки его на сервер было бы лучшей идеей?

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

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

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

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

Вероятно шестнадцатеричное представление.

X означает, что следующее за ним число является шестнадцатеричным (0-9 + AF).

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

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

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