La branche distante de git-svn est à peu près la même qu'une télécommande Git classique. Ainsi, dans votre référentiel local, vous pouvez avoir votre clone git-svn et envoyer les modifications vers GitHub. Git s'en fiche. Si vous créez votre clone git-svn et que vous transférez exactement les mêmes modifications vers GitHub, vous aurez un miroir non officiel du référentiel Google Code. Le reste est à la vanille Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master
Maintenant que vous l'avez, vous devrez parfois synchroniser le référentiel Subversion avec Git. Cela ressemblera à 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 quand vous courrez git svn rebase, vous auriez ceci:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Donc, maintenant, l'exécution git pushpousserait ces commits vers GitHub, la branche [remotes / origin / master] là-bas. Et vous reviendriez au scénario du premier diagramme d'art ASCII.
Le problème maintenant est, comment intégrez-vous vos changements dans le mix? L'idée est que vous ne vous engagez 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 finiriez par rebaser vos modifications par-dessus celles de Subversion, ce qui pourrait déranger quiconque clonerait votre référentiel Git. Suivez-moi? OK, donc vous créez une branche, appelons-la "fonctionnalités". Et vous faites un commit et le poussez sur GitHub dans la branche des fonctionnalités. Votre gitk ressemblerait à ceci:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Ici, vous avez votre branche de fonctionnalités quelques commits avant la branche Google Code, n'est-ce pas? Alors, que se passe-t-il lorsque vous souhaitez intégrer de nouveaux éléments de Google Code? Vous courriez en git svn rebasepremier et obtiendriez ceci:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
Si vous git pushmaîtrisez, vous pouvez imaginer que les [télécommandes / origine / maître] se trouvent au même point que le maître. Mais votre branche de fonctionnalités n'a pas les changements. Vous avez maintenant le choix de fusionner le maître 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 transférez des fonctionnalités sur GitHub. J'ai laissé les télécommandes au maître pour économiser de l'espace, elles seraient au même point que [maître] .
L'approche de rebase est légèrement plus diabolique - vous devrez pousser avec --force car votre poussée ne serait pas une fusion rapide (vous tireriez la branche des fonctionnalités sous quelqu'un qui l'avait clonée). Ce n'est pas vraiment considéré comme acceptable de le faire, mais personne ne peut vous arrêter si vous êtes déterminé. Cela facilite également certaines choses, par exemple lorsque les correctifs sont acceptés en amont sous une forme légèrement retravaillée. Cela vous éviterait d'avoir à vous soucier des conflits, vous pouvez simplement rebaser - ignorer les correctifs en amont. Quoi qu'il en soit, un rebase serait comme ceci:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Et puis vous auriez à git push --forcecela. Vous pouvez voir pourquoi vous devez le forcer, l'historique a un gros schisme ancien entre les [télécommandes / origine / fonctionnalités] et les nouvelles [fonctionnalités] actuelles après le rebase .
Tout cela fonctionne, mais cela demande beaucoup d'efforts. Si vous voulez être un contributeur régulier, le mieux serait de travailler comme ça pendant un certain temps, d'envoyer des correctifs en amont et de voir si vous pouvez obtenir un accès de validation à Subversion. À défaut, ne transmettez peut-être pas vos modifications à GitHub. Gardez-les locaux et essayez quand même de les faire accepter en amont.
gitnoob ici.) Question rapide. Je l'ai fait contre un grand repo SVN et il est sorti à ~ 141 mégaoctets. Je l'ai poussé sur github, puis je l'ai cloné à nouveau, et il est sorti à 130 mégaoctets. J'ai courugit gcsur les deux. Qu'est-ce qui pourrait expliquer la différence?