La branche distante à partir de git-svn est à peu près la même chose que régulier Git remote. Donc, dans votre dépôt local, vous pouvez avoir votre git-svn clone et pousser les changements de GitHub. Git n'a pas de soins. Si vous créez votre git-svn clone et pousser exactement les mêmes changements à GitHub, vous aurez officieux de miroir de la Google référentiel de Code. Le reste est de 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 avez cette, de temps en temps, vous aurez à synchroniser le dépôt Subversion avec Git. Ça va ressembler à quelque chose comme:
git svn rebase
git push
Dans gitk ou que ce soit, ce serait ressembler à ceci:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
Et lorsque vous exécutez git svn rebase, vous avez ceci:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Donc maintenant en cours d'exécution git push pousser ceux s'engage à GitHub, le [remotes/origin/master] de la branche. Et vous seriez de retour au scénario dans la première ASCII art diagramme.
Le problème est maintenant, comment travaillez-vous vos modifications dans le mélange? L'idée est, vous ne jamais s'engager sur la même branche que vous êtes git-svn rebase-ing et git-pousse. Vous avez besoin d'une branche distincte pour vos changements. Sinon, vous vous retrouvez rebasage vos changements sur le dessus de la Subversion, ce qui peut fâcher personne qui les clones de votre dépôt Git. Suivez-moi? OK, donc vous créez une branche, appelons-les "fonctionnalités". Et vous faites un commit et le pousser à GitHub pour les fonctions de direction générale. Votre gitk ressemblerait à quelque chose comme ceci:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Ici vous avez les caractéristiques de votre branche d'un couple de s'engage devant le Google Code de la branche, non? Donc ce qui arrive quand vous voulez intégrer de nouvelles choses à partir de Google Code? Vous passerais git svn rebase première et d'obtenir ceci:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
Si vous git push master, vous pouvez imaginer l' [remotes/origin/master] être au même point que maître. Mais votre branche n'a pas les changements. Vos choix sont maintenant de fusionner master en fonctionnalités, ou rebase fonctionnalités. Une fusion pourrait ressembler à ceci
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Puis vous appuyez sur des fonctionnalités de GitHub. J'ai quitté les télécommandes pour maître pour économiser de l'espace, ils seraient au même point que [master].
Le rebase approche est un peu plus mal que vous auriez à pousser avec --force que votre poussée ne serait pas une avance rapide de fusion (vous devez tirez sur les caractéristiques de la branche de la vertu de quelqu'un qui avait cloné). Ce n'est pas vraiment considéré comme OK pour le faire, mais personne ne peut vous arrêter si vous êtes déterminé. Il ne rendre les choses plus facile aussi, comme lorsque des correctifs être accepté en amont légèrement retravaillé la forme. Ça évitera d'avoir à se soucier des conflits, vous pouvez simplement rebase --skip la upstreamed patchs. De toute façon, un rebase serait comme ceci:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Et ensuite, vous avez en git push --force . Vous pouvez voir pourquoi vous avez besoin de forcer, l'histoire a un gros vieux schisme de l' [remotes/origin/fonctionnalités] pour le nouveau courant de l'après-rebase [caractéristiques].
Ça fonctionne, mais c'est beaucoup d'effort. Si vous allez être un contributeur régulier, le meilleur pari serait de travailler comme ça pendant un moment, envoyer quelques correctifs en amont et voir si vous pouvez obtenir un accès de commit à la Subversion. À défaut, peut-être ne poussez pas vos modifications à GitHub. Garder les locaux et de les essayer et de les faire accepter en amont de toute façon.
