Удаленная ветка от 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 в ветку функций. Ваш мерзавец будет выглядеть примерно так:
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 освоите, вы можете представить, что [remotes / origin / master] находится в той же точке, что и мастер. Но ваша ветвь функций не имеет изменений. Теперь вы можете объединить мастер с функциями или изменить их. Объединение будет выглядеть так
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Затем вы отправляете функции в GitHub. Я оставил пульты для мастера, чтобы сэкономить место, они будут в той же точке, что и [master] .
Подход ребазирования немного более злой - вам придется нажимать с --force, поскольку ваш толчок не будет быстрым слиянием (вы извлечете ветку функций из-под кого-то, кто его клонировал). Это не считается нормальным, но никто не может остановить вас, если вы полны решимости. Это также делает некоторые вещи проще, например, когда патчи принимаются в апстриме в слегка переработанном виде. Это избавило бы от необходимости возиться с конфликтами, вы можете просто перебазировать - пропустить обновленные патчи. В любом случае, перебаз будет выглядеть так:
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. Держите их локально и в любом случае попытайтесь принять их вверх по течению.