Как я могу выполнить форк и синхронизацию с репозиторием Google Code Subversion, к которому у меня нет доступа на запись, в репозиторий GitHub?

Я хочу иметь возможность разрабатывать свои собственные функции в моем репозитории Git, но я также хочу выполнить синхронизацию с репозиторием Google Code Subversion. Чтобы получить исправления со стороны проекта Google Code.

Я знаю о git-svn и раньше использовал его для восходящего и нисходящего потока в репозиторий Subversion, над которым я имел полный контроль. Но я не знаю, как поддерживать синхронизацию с репозиторием Google Code Subversion.

Удаленная ветка от git-svn почти такая же, как и обычный пульт Git. Таким образом, в вашем локальном репозитории вы можете иметь клон git-svn и отправлять изменения на GitHub. Гиту все равно. Если вы создадите свой клон 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справитесь с мастерством, вы можете представить, что [пульты / origin / master] находятся в той же точке, что и мастер. Но в вашей функциональной ветке изменений нет. Теперь ваш выбор - объединить мастер с функциями или переустановить объекты. Слияние будет выглядеть так

git checkout features
git merge master 

            o [features]
           /|
          / o [remotes/origin/features]
[master] o  |
         |  o
         o /
         |/
         o
         |
         o

Затем вы выкладываете функции на GitHub. Я оставил пульты для мастера, чтобы сэкономить место, они будут в той же точке, что и [мастер] .

Подход с перебазированием немного более зловещий - вам придется нажимать с --force, поскольку ваш push не будет слиянием с быстрой перемоткой (вы вытащите ветку функций из-под того, кто ее клонировал). Это не совсем нормально, но никто не сможет вас остановить, если вы настроены. Это также упрощает некоторые вещи, например, когда патчи принимаются апстримом в слегка переработанной форме. Это избавит от необходимости возиться с конфликтами, вы можете просто перебазировать - пропустите обновленные патчи. В любом случае, перебазирование будет таким:

git rebase master features

         o [features]
         |
         o
         |  o [remotes/origin/features]
[master] o  |
         |  o
         o /
         |/
         o
         |
         o

И тогда вам придется это сделать git push --force. Вы можете понять, почему вам нужно это форсировать, в истории есть большой старый раскол от [пультов / происхождение / особенности] до новых текущих [функций] после перебазирования .

Все это работает, но требует больших усилий. Если вы собираетесь быть постоянным участником, лучше всего будет поработать так некоторое время, разослать несколько патчей вверх и посмотреть, сможете ли вы получить доступ к 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 все сделали. Конечно, если вы сильно расходитесь, вам придется объединять вещи вручную.

Я не совсем уверен, что именно вы хотите, но, конечно, вы можете извлечь из репозитория Subversion и отправить в репозиторий Git из той же рабочей копии. И вы также можете git svn dcommitвернуться в репозиторий Subversion. Однако вы не можете синхронизировать репозиторий GitHub с репозиторием Subversion. Кроме того, если у вас есть коммиты в вашей рабочей копии, которых еще нет в репозитории Subversion, вам нужно будет перебазировать их, если репозиторий Subversion был обновлен, что вынудит вас перейти git push --forceна «новые» коммиты на GitHub.

Я нашел эти инструкции в блоге Ю-Цзе Линя :

Сначала клонируйте репозиторий 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