La rama remota de git-svn es prácticamente la misma que un control remoto Git normal. Entonces, en su repositorio local, puede tener su clon git-svn y enviar los cambios a GitHub. A Git no le importa. Si crea su clon git-svn y envía los mismos cambios a GitHub, tendrá un espejo no oficial del repositorio de Google Code. El resto es vainilla Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master
Ahora que tiene esto, ocasionalmente tendrá que sincronizar el repositorio de Subversion con Git. Se verá algo así como:
git svn rebase
git push
En gitk o lo que sea, esto se vería así:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
Y cuando corras git svn rebase, tendrías esto:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Así que ahora ejecutar git pushenviaría esos commits a GitHub, el [control remoto / origen / maestro] rama allí. Y volvería 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 en la misma rama en la que estás git-svn-rebase-ing y git-empujando. Necesita una rama separada para sus cambios. De lo contrario, terminaría cambiando sus cambios sobre los de Subversion, lo que podría molestar a cualquiera que clone su repositorio Git. ¿Sígueme? OK, entonces creas una rama, llamémosla "características". Y se compromete y lo envía a GitHub a la rama de características. Tu gitk se vería así:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Aquí tienes tu rama de características un par de confirmaciones antes de la rama de Google Code, ¿verdad? Entonces, ¿qué sucede cuando quieres incorporar cosas nuevas de Google Code? Corres git svn rebaseprimero y obtienes esto:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
Si git pushdomina, puede imaginar que [remotes / origin / master] está en el mismo punto que master. Pero su rama de características no tiene los cambios. Sus opciones ahora son fusionar master en funciones o volver a crear características. 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 envías funciones a GitHub. He dejado los controles remotos para que master ahorre espacio, estarían en el mismo punto que [master] .
El enfoque de rebase es un poco más malvado: tendría que presionar con fuerza, ya que su empuje no sería una fusión de avance rápido (sacaría la rama de características de debajo de alguien que la clonó). Realmente no se considera correcto hacer esto, pero nadie puede detenerte si estás decidido. También facilita algunas cosas, como cuando los parches se aceptan en sentido ascendente en forma ligeramente modificada. Ahorraría tener que meterse con los conflictos, solo puede volver a redactar, omitir los parches actualizados. 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 luego tendrías que hacer git push --forceeso. Puede ver por qué necesita forzarlo, la historia tiene un gran cisma desde los [controles remotos / origen / características] hasta el nuevo post-rebase actual [características] .
Todo esto funciona, pero es mucho esfuerzo. Si va a ser un contribuyente habitual, la mejor opción sería trabajar así durante un tiempo, enviar algunos parches en sentido ascendente y ver si puede obtener acceso de confirmación a Subversion. De lo contrario, tal vez no envíe sus cambios a GitHub. Manténgalos locales e intente que sean aceptados río arriba de todos modos.
gitnovato 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. Corrígit gcen ambos. ¿Qué podría explicar la diferencia?