Il ramo remoto di git-svn è praticamente lo stesso di un normale telecomando Git. Quindi nel tuo repository locale puoi avere il clone git-svn e inviare le modifiche a GitHub. A Git non interessa Se crei il tuo clone git-svn e invii le stesse esatte modifiche a GitHub, avrai un mirror non ufficiale del repository di Google Code. Il resto è vaniglia Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin [email protected]:example/example.git
git push origin master
Ora che si dispone di questo, di tanto in tanto sarà necessario sincronizzare il repository Subversion con Git. Sarà simile a:
git svn rebase
git push
In gitk o qualsiasi altra cosa, questo sarebbe simile a questa:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
E quando si esegue git svn rebase, si dovrebbe avere questo:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Quindi, con lo git push, è possibile inviare tali commit a GitHub, il ramo [remotes/origin/master]. E torneresti allo scenario nel primo diagramma artistico ASCII.
Il problema ora è: come lavori le tue modifiche nel mix? L'idea è che non ti impegni mai nello stesso ramo in cui sei git-svn-rebase-ing e git-push. Hai bisogno di un ramo separato per le tue modifiche. Altrimenti, finirai per ridefinire le tue modifiche in cima a quelle di Subversion, cosa che potrebbe sconvolgere chiunque cloni il tuo repository Git. Seguimi? OK, quindi crei un ramo, chiamiamolo "caratteristiche". E fai un commit e spingilo a GitHub verso il ramo delle funzionalità. Il tuo gitk sarebbe simile a questa:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Qui hai la tua Branch include un paio di impegna in vista della filiale Google Code, giusto? Quindi cosa succede quando vuoi incorporare nuove cose da Google Code? Faresti esegue git svn rebase prima e ottenere questo:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o/
|/
o[remotes/origin/master]
|
o
Se git push padrone fuori, si può immaginare l'[telecomandi/origin/master] essendo allo stesso punto come master. Ma il tuo ramo di funzionalità non ha le modifiche. Ora le tue scelte sono di unire il master in feature o rebase feature.Una fusione sarebbe simile a questa
git checkout features
git merge master
o [features]
/|
/o [remotes/origin/features]
[master] o |
| o
o/
|/
o
|
o
Poi spingere caratteristiche fuori a GitHub. Ho lasciato fuori i telecomandi per il master per risparmiare spazio, sarebbero nello stesso punto di [master].
L'approccio di rebase è leggermente più malvagio - dovresti spingere con forza perché la tua spinta non sarebbe un'unione di avanzamento rapido (dovresti estrarre il ramo di funzionalità da qualcuno che lo ha clonato). Non è davvero considerato OK farlo, ma nessuno può fermarti se sei determinato. Rende anche alcune cose più semplici, come quando le patch vengono accettate a monte in forma leggermente rielaborata. Risparmierebbe con i conflitti, si può semplicemente rebase --skip le patch upstreamed. In ogni caso, un rebase sarebbe come questo:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o/
|/
o
|
o
E poi si dovrebbe git push --force questo. Puoi vedere perché hai bisogno di forzarlo, la storia ha un grande vecchio scisma dal [remotes/origine/caratteristiche] al nuovo attuale postbase [caratteristiche].
Tutto questo funziona, ma è un grande sforzo. Se si vuole essere un contributore normale, la soluzione migliore sarebbe quella di lavorare in questo modo per un po ', inviare alcune patch upstream e vedere se è possibile ottenere l'accesso di commit a Subversion. In caso contrario, forse non inviare le tue modifiche a GitHub. Tienili locali e prova a farli accettare a monte comunque.
Grazie per le eccellenti istruzioni. ('git' noob qui.) Domanda veloce. Ho fatto questo contro un grande repo SVN ed è uscito a ~ 141 megabyte. L'ho spinto a github e poi lo ho clonato indietro, ed è uscito a 130 megabyte. Ho eseguito 'git gc' su entrambi. Cosa potrebbe spiegare la differenza? – mpontillo
... capito. Mi serviva 'git push origin --mirror'. – mpontillo
Ha funzionato come un incantesimo, ora ho solo bisogno di dire agli sviluppatori googlecode originali di usare github con me: D – electblake