Разветвите и синхронизируйте репозиторий Google Code Subversion с GitHub
Как я могу разветвляться и поддерживать синхронизацию с репозиторием Google Code Subversion, к которому у меня нет прав на запись, в репозиторий GitHub?
Я хочу иметь возможность разрабатывать свои собственные функции в своем репозитории Git, но я также хочу синхронизироваться с репозиторием Google Code Subversion. Получить исправления со стороны проекта Google Code.
Я знаю о git-svn и использовал его прежде, чтобы переходить вверх и вниз по течению к хранилищу Subversion, над которым у меня был полный контроль. Но я не знаю, как поддерживать синхронизацию с хранилищем Google Code Subversion.
7 ответов
Удаленная ветка от git-svn почти такая же, как и у обычного Git. Таким образом, в вашем локальном репозитории вы можете получить клон git-svn и отправить изменения в GitHub. Git не волнует. Если вы создадите свой клон git-svn и внесете те же самые изменения в GitHub, у вас будет неофициальное зеркало репозитория Google Code. Остальное ванильный Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master
Теперь, когда у вас это есть, иногда вам придется синхронизировать репозиторий Subversion с Git. Это будет выглядеть примерно так:
git svn rebase
git push
В gitk или как-то еще это будет выглядеть примерно так:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
И когда ты бежишь git svn rebase, у вас будет это:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Так что теперь работает git push отправит эти коммиты в GitHub, ветку [remotes / origin / master]. И вы вернетесь к сценарию в первой диаграмме ASCII.
Проблема сейчас в том, как вы вносите свои изменения в микс? Идея в том, что вы никогда не делаете коммит на ту же ветку, что и git-svn-rebase-ing и git-pushing. Вам нужна отдельная ветка для ваших изменений. В противном случае вы в конечном итоге отменили бы свои изменения над изменениями Subversion, что может расстроить любого, кто клонирует ваш Git-репозиторий. Подписывайтесь на меня? Итак, вы создаете ветку, давайте назовем это "функции". И вы делаете коммит и отправляете его на GitHub в ветку функций. Ваш gitk будет выглядеть примерно так:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Здесь у вас есть ветка функций на пару коммитов перед веткой Google Code, верно? Так что же произойдет, если вы захотите добавить новый материал из Google Code? Ты бы побежал git svn rebase сначала и получите это:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
если ты git push мастер, вы можете представить, что [пульты / источник / мастер] находятся в той же точке, что и мастер. Но ваша ветвь функций не имеет изменений. Теперь ваш выбор - объединить мастер с функциями или изменить их. Слияние будет выглядеть так
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Затем вы отправляете функции в GitHub. Я оставил пульты для мастера, чтобы сэкономить место, они будут в той же точке, что и [мастер].
Подход rebase немного более злой - вам придется нажимать с --force, поскольку ваш push не будет слиянием с ускоренной перемоткой вперед (вы вытянете ветвь функций из-под кого-то, кто ее клонировал). Это не считается нормальным, но никто не может остановить вас, если вы полны решимости. Это также делает некоторые вещи проще, например, когда патчи принимаются в апстриме в слегка переработанном виде. Это избавило бы от необходимости возиться с конфликтами, вы можете просто перебазировать - пропустить обновленные патчи. В любом случае, перебаз будет выглядеть так:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
И тогда вам придется git push --force тот. Вы можете понять, зачем вам это нужно, история имеет большой старый раскол от [remotes / origin / features] до нового текущего постбазирования [features].
Это все работает, но это много усилий. Если вы собираетесь стать постоянным участником, лучше всего поработать так некоторое время, отправить несколько патчей в апстрим и посмотреть, сможете ли вы получить коммитный доступ к Subversion. В противном случае, возможно, не выдвигайте свои изменения в GitHub. Держите их локальными и попытайтесь принять их в любом случае вверх по течению.
сервис svn2github
Веб-сайт http://svn2github.com/ предоставляет сервис для размещения любого общедоступного SVN-репозитория на Github (по адресу https://github.com/svn2github/projectname). Я попробовал это; после нажатия "Сделать зеркало" он, очевидно, ничего не делал в течение нескольких секунд и отображал сообщение "ошибка", но на самом деле это работало. Фактически был создан новый репозиторий, содержащий код из репозитория SVN.
Затем вы создадите репозиторий, который он создает, и будете работать на своем собственном форке. Затем вы отправите свои изменения в основной проект, используя их багтрекер.
Глядя на существующие репозитории под пользователем сервиса Github (например, "svn2github отправлен на мастер-версию на svn2github/haxe 5 часов назад"), он, похоже, регулярно извлекает изменения из репозитория SVN. На сайте нет информации о том, кто запускает службу, поэтому я бы не поспорил, что она будет продолжать работать бесконечно, но пока она работает (и если она когда-нибудь выйдет из строя, вы все равно можете вручную обновить свой форк).
Launchpad
Если вы не настроены на использование Git и Github, другой альтернативой является использование Launchpad.net. Launchpad может автоматически импортировать SVN (также CVS) репозитории в личную ветку bzr. Для этого создайте проект Launchpad, затем перейдите на новую страницу импорта, выберите Subversion и введите URL (например, http://projectname.googlecode.com/svn/trunk/). В зависимости от размера проекта первоначальный импорт может занять до нескольких часов. Последующий импорт будет выполняться периодически.
Для получения дополнительной документации см. Импорт VCS в справке Launchpad.
Пошаговое руководство по синхронизации Google Code с GitHub доступно на сайте fnokd.com. Автор использует всегда включенный удаленный сервер и задание cron для автоматизации синхронизации и сохраняет транк SVN в ветви GitHub, называемой "vendor".
GitHub теперь поддерживает прямой импорт проектов Subversion (см. http://help.github.com/import-from-subversion/). Просто создайте новый репозиторий и нажмите "Импорт из Subversion" на экране "Следующие шаги". Он не поддерживает дальнейшую синхронизацию:/.
Хм.. В моей компании я делал почти то же самое. Просто наличие обоих.svn и.git репо в одном каталоге (вы извлекаете svn репо и создаете git репо в этой рабочей копии).
Затем с помощью svn up и git push это удалось. Конечно, если вы сильно расходитесь, вам придется объединять вещи вручную.
Я нашел эти инструкции в блоге Yu-Jie Lin:
Сначала клонируйте хранилище Subversion и нажмите на Git:
git svn clone https://foo.googlecode.com/svn/ git-foo
cd git-foo
git remote add git-foo git@github.com:username/foo.git
git push git-foo master
После фиксации в хранилище Subversion запустите
cd /path/to/git-foo
git svn fetch
git svn rebase
git push git-foo master
Я не совсем уверен, что вы хотите, но, конечно, вы можете извлечь из хранилища Subversion и отправить в хранилище Git из той же рабочей копии. И вы также можете git svn dcommit вернуться в хранилище Subversion. Вы не можете синхронизировать репозиторий GitHub с хранилищем Subversion. Кроме того, когда в вашей рабочей копии есть коммиты, которых еще нет в хранилище Subversion, вам нужно будет перебазировать их, если хранилище Subversion было обновлено, заставляя вас git push --force "новый" коммит на GitHub.