Il ramo remoto di git-svn è praticamente lo stesso di un normale telecomando Git. Quindi nel tuo repository locale puoi avere il tuo clone git-svn e inviare le modifiche a GitHub. A Git non importa. Se crei il tuo clone git-svn e invii esattamente le stesse modifiche a GitHub, avrai un mirror non ufficiale del repository Google Code. Il resto è vaniglia Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master
Ora che hai questo, a volte dovrai sincronizzare il repository Subversion con Git. Sarà simile a:
git svn rebase
git push
In gitk o altro, questo sarebbe simile a questo:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
E quando corri git svn rebase, avresti questo:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Quindi ora correndo git pushsi spingerebbe fuori il commit di GitHub, il ramo [telecomandi / origine / master] lì. E torneresti allo scenario nel primo diagramma di arte ASCII.
Il problema ora è: come si modificano le modifiche nel mix? L'idea è che non ti impegni mai nello stesso ramo in cui stai git-svn-rebase-ing e git-push. È necessario un ramo separato per le modifiche. Altrimenti, finiresti per riorganizzare le tue modifiche in aggiunta a quelle di Subversion, il che potrebbe sconvolgere chiunque cloni il tuo repository Git. Seguimi? OK, quindi crei un ramo, chiamiamolo "caratteristiche". E fai un commit e lo invii a GitHub nel ramo delle funzionalità. Il tuo gitk sarebbe simile a questo:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Qui hai un ramo delle tue funzioni un paio di commit prima del ramo di Google Code, giusto? Quindi cosa succede quando desideri incorporare nuovi elementi da Google Code? Dovresti correre per git svn rebaseprimo e ottenere questo:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
Se sei git pushesperto, puoi immaginare che [telecomandi / origine / master] si trovano nello stesso punto del master. Ma la sezione delle funzionalità non presenta le modifiche. Le tue scelte ora sono di fondere il master in funzionalità o di modificare le funzionalità. Una fusione sarebbe simile a questa
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Quindi invii le funzionalità a GitHub. Ho lasciato i telecomandi per master per risparmiare spazio, sarebbero allo stesso punto di [master] .
L'approccio rebase è leggermente più malvagio - dovresti spingere con - forza poiché la tua spinta non sarebbe una fusione rapida (tireresti il ramo delle caratteristiche da sotto qualcuno che lo aveva clonato). Non è davvero corretto fare questo, ma nessuno può fermarti se sei determinato. Rende anche alcune cose più facili, come quando le patch vengono accettate a monte in forma leggermente rielaborata. Eviterebbe di dover fare confusione con i conflitti, puoi semplicemente riformulare - salta le patch a monte. Ad ogni modo, un rebase sarebbe così:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
E poi dovresti farlo git push --force. Puoi capire perché devi forzarlo, la storia ha un grande vecchio scisma dai [telecomandi / origine / caratteristiche] alla nuova attuale post-rebase [caratteristiche] .
Tutto funziona, ma è un grande sforzo. Se hai intenzione di contribuire regolarmente, la soluzione migliore sarebbe quella di lavorare in questo modo per un po ', inviare alcune patch a monte e vedere se riesci a ottenere l'accesso commit a Subversion. In caso contrario, forse non inviare le modifiche a GitHub. Mantienili locali e cerca comunque di farli accettare a monte.
gitNoob qui.) Domanda veloce. Ho fatto questo contro un grande repository SVN ed è uscito a ~ 141 megabyte. L'ho spinto su github e poi l'ho clonato di nuovo in basso, ed è uscito a 130 megabyte. Ho corsogit gcsu entrambi. Cosa potrebbe spiegare la differenza?