La rama remota de git-svn es prácticamente la misma que la de un control remoto regular de Git. Entonces en su repositorio local puede tener su clon git-svn y enviar cambios a GitHub. A Git no le importa Si crea su clon git-svn y envía exactamente los mismos cambios a GitHub, tendrá un espejo no oficial del repositorio de Google Code. El resto es Vanilla Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin [email protected]:example/example.git
git push origin master
Ahora que tiene esto, ocasionalmente tendrá que sincronizar el repositorio de Subversion con Git. Se verá algo como:
git svn rebase
git push
En gitk o lo que sea, esto sería algo como esto:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
Y cuando se ejecuta git svn rebase, que tendría esto:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Así que ahora ejecutando git push empujará esos commits a GitHub, la rama [remotes/origin/master] allí. Y volverás al escenario en el primer diagrama de arte ASCII.
El problema ahora es, ¿cómo trabajas tus cambios en la mezcla? La idea es que nunca te comprometas con la misma rama que eres git-svn-rebase-ing y git-pushing. Necesita una sucursal separada para sus cambios. De lo contrario, terminarías redefiniendo tus cambios sobre los de Subversion, lo que podría molestar a cualquiera que clone tu repositorio de Git. ¿Sígueme? De acuerdo, entonces crea una rama, llamémosla "características". Y haces una confirmación y la envías a GitHub a la rama de características. Su gitk sería algo como esto:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Aquí tienes tu sucursal cuenta con un par de confirmaciones por delante de la rama de Google Code, ¿verdad? Entonces, ¿qué sucede cuando quieres incorporar cosas nuevas de Google Code? Que había corrido git svn rebase primera y obtener esto:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o/
|/
o[remotes/origin/master]
|
o
Si git push master out, se puede imaginar el [mandos a distancia/origin/master] estar en el mismo punto que amo. Pero su rama de características no tiene los cambios. Sus opciones ahora son fusionar el maestro en características o funciones de rebase.Una fusión se vería así
git checkout features
git merge master
o [features]
/|
/o [remotes/origin/features]
[master] o |
| o
o/
|/
o
|
o
Luego, presiona las funciones en GitHub. He dejado los controles remotos para que el maestro ahorre espacio, estarían en el mismo punto que [maestro].
El enfoque de rebase es un poco más maligno - tendrías que presionar con --force ya que tu empujón no sería una fusión de avance rápido (sacarías la rama de funciones de debajo de alguien que la había clonado). Realmente no se considera correcto hacer esto, pero nadie puede impedirte si estás decidido. También facilita algunas cosas, como cuando los parches son aceptados en sentido ascendente en una forma ligeramente retrabajada. Ahorraría tener que lidiar con conflictos, simplemente puede rebase - omita los parches ascendentes. De todos modos, un rebase sería así:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o/
|/
o
|
o
Y entonces tendría que git push --force eso. Puede ver por qué necesita forzarlo, la historia tiene un gran cisma antiguo del [controles remotos/características/características] a la nueva posreposición actual [características].
Todo esto funciona, pero es un gran esfuerzo. Si vas a ser un colaborador habitual, la mejor opción sería trabajar así durante un tiempo, enviar algunos parches de subida y ver si puedes obtener acceso de confirmación a Subversion. De lo contrario, quizás no envíe sus cambios a GitHub. Manténgalos locales e intente que sean aceptados aguas arriba de todos modos.
Gracias por las excelentes instrucciones. ('git' noob aquí.) Pregunta rápida. Hice esto contra un gran repositorio SVN y salió a ~ 141 megabytes. Lo empujé a github y luego lo cloné de nuevo, y salió a 130 megabytes. Ejecuté 'git gc' en ambos. ¿Qué podría explicar la diferencia? – mpontillo
... lo descubrí. Necesitaba 'git push origin --mirror'. – mpontillo
Funcionó como un amuleto, ahora solo necesito decirle a los desarrolladores originales de googlecode que usen github conmigo: D – electblake