A ramificação remota do git-svn é praticamente a mesma de um remoto Git comum. Portanto, em seu repositório local, você pode ter seu clone git-svn e enviar as alterações para o GitHub. Git não se importa. Se você criar seu clone git-svn e enviar exatamente as mesmas alterações para o GitHub, terá um espelho não oficial do repositório do Google Code. O resto é baunilha Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master
Agora que você tem isso, ocasionalmente você terá que sincronizar o repositório do Subversion com o Git. Será algo como:
git svn rebase
git push
No gitk ou o que seja, isso seria algo como isto:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
E quando você executa git svn rebase, você terá o seguinte:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Portanto, agora a execução git pushenviaria esses commits para o GitHub, o ramo [remotes / origin / master] lá. E você voltaria ao cenário no primeiro diagrama de arte ASCII.
O problema agora é: como você trabalha suas alterações no mix? A idéia é que você nunca se comprometa com o mesmo ramo em que está git-svn-rebase-ing e git-push. Você precisa de uma ramificação separada para suas alterações. Caso contrário, você acabaria reorganizando suas alterações sobre as do Subversion, o que poderia incomodar qualquer um que clona seu repositório Git. Me siga? OK, então você cria um ramo, vamos chamá-lo de "recursos". E você faz um commit e o envia ao GitHub para o ramo de recursos. Seu gitk ficaria assim:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Aqui você tem seus recursos ramificados alguns commits à frente do ramo do Google Code, certo? Então, o que acontece quando você deseja incorporar novidades do Google Code? Você executaria git svn rebaseprimeiro e obteria o seguinte:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
Se você git pushdominar, poderá imaginar os [controles remotos / origem / mestre] no mesmo ponto que o mestre. Mas o seu ramo de recursos não possui as alterações. Agora, suas escolhas são mesclar o mestre em recursos ou reestruturar recursos. Uma mesclagem ficaria assim
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Em seguida, você envia os recursos para o GitHub. Deixei os controles remotos para o mestre economizar espaço, eles estariam no mesmo ponto que o [mestre] .
A abordagem de rebase é um pouco mais ruim - você precisaria pressionar com --force, pois seu push não seria uma mesclagem de avanço rápido (você puxaria o ramo de recursos de baixo de alguém que o clonou). Não é realmente bom fazer isso, mas ninguém pode impedi-lo se você estiver determinado. Isso também facilita algumas coisas, como quando os patches são aceitos upstream na forma ligeiramente reformulada. Isso pouparia ter que mexer com conflitos, você pode apenas refazer a ação - ignorar os patches anteriores. De qualquer forma, uma rebase seria assim:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
E então você teria que fazer git push --forceisso. Você pode ver por que você precisa forçá-lo, a história tem um grande e velho cisma, desde [controles remotos / origem / recursos] até os novos [recursos] pós-rebase atuais .
Tudo isso funciona, mas é muito esforço. Se você for um colaborador regular, a melhor aposta seria trabalhar assim por um tempo, enviar alguns patches a montante e ver se você pode obter acesso de confirmação ao Subversion. Caso contrário, talvez não envie suas alterações para o GitHub. Mantenha-os locais e tente aceitá-los de qualquer maneira.
gitnoob aqui.) Pergunta rápida. Fiz isso contra um grande repositório SVN e chegou a ~ 141 megabytes. Empurrei-o para o github e depois o clonei de volta, e ele saiu para 130 megabytes. Eu corrigit gcem ambos. O que poderia explicar a diferença?