Forkez et synchronisez le référentiel Google Code Subversion dans GitHub
Comment puis-je bifurquer et rester synchronisé avec un référentiel Google Code Subversion auquel je n'ai pas accès en écriture dans un référentiel GitHub?
Je veux pouvoir développer mes propres fonctionnalités dans mon référentiel Git, mais je veux également me synchroniser avec le référentiel Google Code Subversion. Pour récupérer les correctifs du côté du projet Google Code.
Je connais git-svn et je l'ai utilisé auparavant pour monter et descendre dans un dépôt Subversion sur lequel j'avais un contrôle total. Mais je ne sais pas comment rester synchronisé avec un référentiel Google Code Subversion.
La branche distante de git-svn est à peu près la même qu'une télécommande Git ordinaire. Ainsi, dans votre référentiel local, vous pouvez avoir votre clone git-svn et pousser les modifications vers GitHub. Git s'en fiche. Si vous créez votre clone git-svn et transférez exactement les mêmes modifications vers GitHub, vous aurez un miroir non officiel du référentiel de codes Google. Le reste est Vanilla 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, 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 à 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
Alors en cours d'exécution git Push pousserait ces commits vers GitHub, la branche [remotes/Origin/master] là-bas. Et vous seriez de retour au scénario dans le premier diagramme artistique ASCII.
Le problème est maintenant, comment travaillez-vous vos changements dans le mix? L'idée est que vous ne vous engagez jamais sur la même branche que vous git-svn-rebase-ing et git-push. 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 perturber quiconque clone 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 vers 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 validations avant la branche Google Code, non? Alors, que se passe-t-il lorsque vous souhaitez intégrer de nouveaux éléments de Google Code? Vous exécuteriez 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 master out, vous pouvez imaginer que [télécommandes/origine/master] étant au même point que master. Mais votre branche de fonctionnalité n'a pas les changements. Vos choix sont maintenant de fusionner le master en fonctionnalités ou de rebaser des 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 que master économise de l'espace, elles seraient au même point que [master].
L'approche de rebase est légèrement plus maléfique - vous devriez 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 correct de le faire, mais personne ne peut vous arrêter si vous êtes déterminé. Cela facilite également certaines choses, comme 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 il faudrait git Push --force cette. Vous pouvez voir pourquoi vous devez le forcer, l'historique a un gros vieux schisme du [télécommandes/origine/fonctionnalités] au nouveau post-rebase actuel [fonctionnalités] .
Tout cela fonctionne, mais cela demande beaucoup d'efforts. Si vous allez ê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 de les faire accepter en amont de toute façon.
service svn2github
Le site Web http://svn2github.com/ fournit un service pour bifurquer n'importe quel dépôt SVN accessible au public sur Github (à https://github.com/svn2github/projectname ). Je l'ai essayé; en appuyant sur "Faire un miroir", il n'a apparemment rien fait pendant quelques secondes et a affiché le message "erreur", mais cela a fonctionné. Le nouveau dépôt a en fait été créé, contenant le code du repo SVN.
Vous devez ensuite bifurquer le référentiel qu'il crée et travailler sur votre propre fork. Vous soumettriez alors vos modifications au projet en amont en utilisant leur bugtracker.
En regardant les référentiels existants sous l'utilisateur Github du service (par exemple, "svn2github poussé à maîtriser sur svn2github/haxe il y a 5 heures"), il semble que des modifications soient régulièrement apportées par le référentiel SVN. Il n'y a aucune information sur qui gère le service sur le site Web, donc je ne parierais pas qu'il continue de fonctionner indéfiniment, mais cela fonctionne pour le moment (et si jamais il tombe en panne, vous pouvez toujours mettre à jour manuellement votre fork).
Rampe de lancement
Si vous n'êtes pas prêt à utiliser Git et Github, une autre alternative consiste à utiliser Launchpad.net. Launchpad peut importer automatiquement les référentiels SVN (également CVS) dans une branche bzr personnelle. Pour ce faire, créez un projet Launchpad, puis accédez à la nouvelle page d'importation , sélectionnez Subversion et entrez l'URL (par exemple http://projectname.googlecode.com/svn/trunk/). Selon la taille du projet, l'importation initiale peut prendre jusqu'à quelques heures. Les importations ultérieures se dérouleront périodiquement.
Pour plus de documentation, voir VCS Imports on Launchpad Help .
Une procédure pas à pas pour la synchronisation de Google Code vers GitHub est disponible sur fnokd.com . L'auteur utilise un serveur distant toujours actif et un travail cron pour automatiser la synchronisation et conserve le tronc SVN dans une branche GitHub appelée "vendeur".
GitHub prend désormais en charge l'importation directe de projets Subversion (voir http://help.github.com/import-from-Subversion/ ). Créez simplement un nouveau référentiel, puis cliquez sur "Importer depuis Subversion" sur l'écran "Étapes suivantes". Cependant, il ne prend pas en charge la synchronisation: /.
Hmm .. Dans mon entreprise, je faisais presque la même chose. Il suffit d'avoir à la fois .svn et .git repo dans le même répertoire (vous extrayez svn repo et créez git repo dans cette copie de travail).
Ensuite, utiliser svn up et git Push a fait le truc. Bien sûr, si vous divergez beaucoup, vous devrez fusionner les choses à la main.
Je ne sais pas trop ce que vous voulez mais, bien sûr, vous pouvez extraire d'un référentiel Subversion et pousser vers un référentiel Git à partir de la même copie de travail. Et vous pouvez également git svn dcommit retour au référentiel Subversion. Cependant, vous ne pouvez pas synchroniser le référentiel GitHub avec le référentiel Subversion. De plus, lorsque vous avez des validations dans votre copie de travail qui ne sont pas encore dans le référentiel Subversion, vous devrez les rebaser si le référentiel Subversion a été mis à jour, vous obligeant à git Push --force le "nouveau" valide GitHub.
J'ai trouvé ces instructions sur le blog de Yu-Jie Lin :
Commencez par cloner le référentiel Subversion et Push to the Git:
git svn clone https://foo.googlecode.com/svn/ git-foo
cd git-foo
git remote add git-foo [email protected]:username/foo.git
git Push git-foo master
Après avoir validé dans le référentiel Subversion, exécutez
cd /path/to/git-foo
git svn fetch
git svn rebase
git Push git-foo master