La branche distante de git-svn est à peu près la même que celle d'une télécommande Git standard. Ainsi, dans votre dépôt local, vous pouvez avoir votre clone git-svn et pousser les changements vers GitHub. Git s'en fout. Si vous créez votre clone git-svn et exportez exactement les mêmes modifications sur GitHub, vous aurez un miroir non officiel du référentiel Google Code. Le reste est vanit Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin [email protected]:example/example.git
git push origin master
Maintenant que vous avez cela, parfois vous devrez synchroniser le dépôt Subversion avec Git. Ça va ressembler à quelque chose comme:
git svn rebase
git push
Dans gitk ou autre, cela ressemblerait à quelque chose comme ceci:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
Et lorsque vous exécutez git svn rebase, vous auriez ceci:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Donc maintenant en cours d'exécution git push pousserait ces commits à GitHub, la branche [distants/origine/maître] là. Et vous reviendrez au scénario dans le premier diagramme artistique ASCII.
Le problème est maintenant, comment travaillez-vous vos changements dans le mélange? L'idée est, vous ne commettez jamais sur la même branche que vous êtes git-svn-rebase-ing et git-pushing. Vous avez besoin d'une branche distincte pour vos modifications. Sinon, vous finirez par rebaser vos modifications sur celles de Subversion, ce qui pourrait contrarier tous ceux qui clonent votre dépôt Git. Suis moi? OK, alors vous créez une branche, appelons-la "fonctionnalités". Et vous faites un commit et le propulsez à GitHub à la branche features. Votre gitk ressemblerait à quelque chose comme ceci:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Ici vous avez votre branche deux caractéristiques engage en avance sur la branche Google Code, droit? Alors que se passe-t-il lorsque vous souhaitez intégrer de nouveaux éléments à partir de Google Code? Vous souhaitez exécuter git svn rebase d'abord et obtenez ceci:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o/
|/
o[remotes/origin/master]
|
o
Si vous git push maître, vous pouvez imaginer le [remotes/origin/master] étant au même point que maître. Mais votre branche de fonctionnalité n'a pas les changements. Vos choix sont maintenant de fusionner le master en fonctionnalités, ou de rebaser les fonctionnalités.Une fusion ressemblerait à ceci:
git checkout features
git merge master
o [features]
/|
/o [remotes/origin/features]
[master] o |
| o
o/
|/
o
|
o
Ensuite, vous poussez les fonctionnalités vers GitHub. J'ai laissé les télécommandes pour maître pour économiser de l'espace, ils seraient au même point que [maître]. L'approche de rebasage est un peu plus mauvaise - vous devriez pousser avec --force car votre poussée ne serait pas une fusion rapide-forward (vous tireriez la branche de caractéristiques sous quelqu'un qui l'avait cloné). Ce n'est pas vraiment acceptable de le faire, mais personne ne peut vous arrêter si vous êtes déterminé. Cela facilite également certaines choses, comme lorsque les patches sont acceptés en amont sous une forme légèrement remaniée. Cela éviterait d'avoir à faire des bêtises avec les conflits, vous pouvez simplement rebasculer --skip les patchs en amont. Quoi qu'il en soit, un rebasage serait comme ceci:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o/
|/
o
|
o
Et vous auriez à git push --force que. Vous pouvez voir pourquoi vous avez besoin de le forcer, l'histoire a un grand vieux schisme des [remotes/origine/caractéristiques] aux nouveaux [caractéristiques] post-rebasage actuel.
Tout cela fonctionne, mais c'est beaucoup d'effort. Si vous allez être un contributeur régulier, le mieux serait de travailler comme ça pendant un moment, d'envoyer des patchs en amont et de voir si vous pouvez obtenir un accès commit à Subversion. A défaut, ne poussez peut-être pas vos changements sur GitHub. Gardez-les locaux et essayez de les faire accepter en amont de toute façon.
Merci pour les excellentes instructions. ('git' noob ici.) Question rapide. Je l'ai fait contre un gros repo SVN et il est sorti à ~ 141 mégaoctets. Je l'ai poussé à github puis je l'ai cloné, et il est sorti à 130 mégaoctets. J'ai couru 'git gc' sur les deux. Qu'est-ce qui pourrait expliquer la différence? – mpontillo
... compris. J'avais besoin de 'git push origin --mirror'. – mpontillo
Travaillé comme un charme, maintenant je dois juste dire à l'original googlecode devs d'utiliser github avec moi: D – electblake