Удаленная ветка от 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. Держите их локально и в любом случае постарайтесь добиться их принятия в апстриме.
gitздесь нуб.) Быстрый вопрос. Я сделал это против большого репо SVN, и получилось ~ 141 мегабайт. Я отправил его на github, а затем клонировал обратно, и получилось 130 мегабайт. Я пробежалсяgit gcпо обоим. Что могло объяснить разницу?